Refactor: Rewrite and simplify the data model for booking

[nt-gt]

The carrier SMEs have decided that there should be one and only one
endpoint for bookings. This means the distinguish between a
BookingRequest and ConfirmedBooking should no longer be entity but
only status level changes.

To prepare for that, I have rewritten the data model with this focus
in mind. In this rewrite, BookingRequest and ConfirmedBooking are
replaced by Booking and BookingData.

The BookingData contains the combined set of attributes from
BookingRequest and ConfirmedBooking with a very few "meta data"
attributes (such as carrierBookingRequestReference,
carrierBookingReference, and the bookingStatus). Everything else
is in the BookingData entity.

Because this is a massive internal rewrite, I made it a goal to keep
the postman test passing running without any changes to the postman
collection. This should give us confidence that this is purely an
internal "implementation-detail"-level rewrite. No externally visible
contracts have chanced.

Other notes:

• Henrik is still working on the updated Swagger specs for the new
  design. It is currently a private draft at DRAFT-SWAGGER

• I made no changes to TOss. Again to avoid changing the postman
  tests. I expect we will able to regnerate those once Henrik is
  done with the swagger rewrite.

  • There are also no externally visisble changes to controllers
    for the same reason. The only change is a rename of a method in a
    service used by a controller).

• Most of the SQL changes is removing now redundant SQL test data.
  Most of it became redundant with the removal of the summaries
  endpoint, but was not removed at the time. I removed it in this
  commit because the data was not used anyway and in some cases
  violated "1-1" constraints (we had multiple ConfirmedBookings
  linking to the BookingRequest, which is no longer possible in
  the new data model design).

• I had to keep some "dead" attributes around (such as the "create"
  and "update" timestamps) because they are required by a JSON schema
  in the postman collection. The reference implementation does not
  maintain these field as strictly as before as they are scheduled
  for removal (DT-389). Just enough to satisify the JSON schema
  requirement to avoid having to touch the postman collection. I
  have spinkled TODO around with a refrence to DT-389 where I thought
  it was relevant.

Signed-off-by: Niels Thykier [email protected]