`optional<T&&>` and `optional<void>` for the completeness of monadic operations

[frederick-vs-ja]

optional<T&&> was once proposed but withdrawn (#70). But I think it's still meaningful in monadic operations.

I guess we can re-introduce it with the construction from T&& disallowed. I think we introduce some helper functions to create them from existing optional<T> lvalues and optional<T&> values, which should avoid most dangling cases.

Additionally, optional<void> also seems to be meaningful in monadic operations (although not elsewhere).

[steve-downey]

Examples of code that doesn't work and ought to is probably the first place to start. There was some disagreement about how optional<T&&> should work, I don't think anything deep, but a concrete design and goal would really help. I didn't want optional<T&> to get delayed because of evolutionary concerns with a new feature.

Since we're never going to get 'Regular Void', figuring out what the APIs should look like for an optional would also be welcome. I think in particular figuring out when evaluation is guaranteed would be important? I'm assuming this is to support the transform operation, and then possibly if an optional exists, the monadic bind?