Why do we allow directly querying schedulers, but require receivers to return a separate environment object?

[lewissbaker]

The receiver concept has receivers provide access to a queryable object representing the execution environment by calling a get_env() member-function.

Similarly, the sender concept has callers get access to the sender's attributes by calling the get_env() member-function.

However, the scheduler concept is defined as implementing the queryable interface itself, rather than having a separate member-function that returns the queryable object.

This seems like an inconsistent API design - ideally we would use the same patterns for queryability here.

We should consider trying to make these consistent by, either:

1. Adding a get_env() member-function to the scheduler concept which returns the scheduler's attributes/environment.
2. Changing the sender and receiver concepts to just be directly queryable, and removing the get_env member-function/cpo.

Note that 2) was the original design before the environment was split out from the receiver to a separate object in an attempt to eliminate some recursive type-dependencies. However, we may need to go back to this design to address some limitations with this split which make it difficult to know whether a child operation's connect() is noexcept until you know the receiver type - something that is needed for computation of completion-signatures for some algorithms which currently only have access to the environment type, not the receiver type. See #247 and #246 for more details on this.