[transmit-case] Ergonomics for Choice<N> bounds

[sdleffler]

Just dumping some thoughts from DMs into a more permanent location.

Currently the issue is that Choice<N> is treated specially when it cannot be, as it is quantified
and the vast majority of types which will be sent via TransmitCase will not be. At current, the
TransmitCase impl for Choice<N> is for all types Choice<LENGTH> for all const LENGTH: usize,
given a TransmitChoice impl. If we keep TransmitCase, add a NotChoice<T> type used for
transmitting non-Choice<N> types, and then add an impl for TransmitCase<NotChoice<T>>
where T: Match + Transmittable, Self: Transmit<T> and then seal TransmitCase, we can provide two
functions for choose which work for Choice<N> and NotChoice<T>. In this case it becomes very
clear how Choice and non-Choice case choosing is so different; they are of different kinds,
specifically one is a parameter of the const usize kind and the other is a type.

However, unless we extend this sealed type distinction to the type-level session language, we are
now forced to have two different variations of the offer! macro. So I propose the following:

• Restrict types allowed in Choose and Offer types to Choice<N> and NotChoice<T>.
• Generate the appropriate output type from the Session! macro, which has the necessary
  information to deal with this.
• Implement Match for NotChoice<T> transparently delegating to the wrapped value.

Given this, the same offer! will happily work for both cases. And we would likely also be able to
have a single implementation of choose that works for both cases as well.