Refactor "availableChannel"

[nickevansuk]

The current definition of availableChannel conflicts with other properties within the specification. This property should be refactored to fix the issues described below, simplify implementations, and ensure that it is fit for purpose going forward.

"availableChannel" is currently defined as the "The channels through which a booking can be made", with values of OpenBookingPrepayment, TelephoneAdvanceBooking, TelephonePrepayment and OnlinePrepayment. It is defined at the Offer level, and its functionality currently overlaps with prepayment and advanceBooking properties that are also defined at the `Offer level.

Additionally:

• Given other types of channel may be referenced at a later date, the name "availableChannel" should be more specific e.g. "bookingChannel"
• prepayment and advanceBooking property definitions should clearly indicate that they relate only to Open Booking, to ensure no overlap in definition. Potentially these should also be renamed to openBookingPrepayment and openBookingInAdvance
• Because prepayment and advanceBooking relate only to Open Booking, it is not required to have bookingChannel defined at the Offer level - as advanceBooking of Unavailable can be used for any Offer that is not available via Open Booking.
• It is therefore possible to move availableChannel / bookingChannel values of TelephoneAdvanceBooking, TelephonePrepayment, OnlinePrepayment (and OnlineAdvanceBooking for completeness) into the Modelling Specification - at the SessionSeries / FacilityUse level, as this level of specificity is not available at the Offer level anyway for all known use cases, and these other values do not relate to Open Booking.
• Given that openBookingPrepayment and openBookingInAdvance are available at the Offer level, the availability of "Open Booking API" for a particular Seller can be specified at the organizer level - which fits with the per-Seller agreements and approval that are required to enable Open Booking.

Hence an additional property should be defined at the Seller level:

• A boolean of allowOpenBooking.

This also allows brokers to easily filter on Sellers based on whether or not they support Open Booking.

This should be reflected in the definition of 8.1 Definition of a 'bookable' Opportunity and Offer pair

[nickevansuk]

Noting that bookingChannel is likely best moved back to a beta property, for future consideration for the modelling spec

[nickevansuk]

This translates into the following updates to the specification and tooling:

• Rename availableChannel at the Offer level to bookingChannel at the opportunity level, and move this back to beta due to lack of adoption (#161)
• Rename prepayment to openBookingPrepayment
• Rename advanceBooking to openBookingInAdvance
• Add oa:isOpenBookingAllowed to Person and Organization, for use in the organizer property.
• Reflect oa:isOpenBookingAllowed in the business logic, replacing the check for availableChannel

[nickevansuk]

Additionally this text describing openBookingInAdvance should be fixed in the specification:

Indicates whether to accept this offer, a Customer must book in advance, whether they must pay on attending, or have option to do either.

Should be

Indicates whether to accept this Offer, a Customer must book in advance (https://openactive.io/Required); or whether a Customer may choose either book in advance or simply "walk-in" without booking in advance (https://openactive.io/Optional). If Open Booking is not available for this Offer (https://openactive.io/Unavailable), the method of booking is specified elsewhere in the data, possibly by the url of the Offer.