design: consider partitions as a separate abstraction from queues

[garlick]

As noted in #5240, partitions may be a useful abstraction, distinct from queues.

My thought is that a Flux partition would be defined so that it implies a scheduler instance operating on a non-overlapping resource subset.

We don't currently allow there to be more than one scheduler so that would require changes to

• 27/Flux Resource Allocation Protocol Version 1
• 28/Flux Resource Acquisition Protocol Version 1
• scheduler configuration - would need per partition tables in the config object

@grondo brought up in #5240 (quoting loosely):

• how partitions and queues would work together (many of our current use cases for queues would probably be served better by partitions)
• how would partitions would be reflected in tools output, etc.
• it might be nice to think about how we could do better with partitions and make them dynamic (e.g. move resources around at runtime instead of requiring sysadmins to write a config file, commit it to version control, distribute it to all nodes, reconfigure and reload modules)