formalize valid requirements specifications

From the discussion [here](https://github.com/jonboulle/fleet/commit/1b42558dad5e378954893669e57e25d1d804115d#commitcomment-6982201)

Basically, from the set of all possible fleet requirements:
- `X-ConditionMachineID` 
- `X-ConditionMachineBootID` (can we scrap this?)
- `X-ConditionMachineOf`
- `X-Conflicts`
- `X-ConditionMachineMetadata`
- `X-MachineMetadata` (can we scrap this?)
- `X-MemoryReservation` (gone)
- `X-DiskReservation` (gone)
- `X-CoresReservation` (gone)

... we need to define which subsets are valid, and I strongly favour blocking invalid permutations at the earliest point (e.g. `fleetctl submit`, API submit)

For example, `X-ConditionMachineID` cannot be used with `X-*Reservation`, or `X-FleetConflicts`, or `X-ConditionMachineOf`. Effectively, `X-ConditionMachineID` triggers a "do not perform any scheduling for this job" condition, and hence is suitable for use by upstream schedulers.

I find the approach of separating out a bunch of constants and helper function pretty hard to read. Not only do I have to follow 3 or 4 function calls to tell what a given test case is asserting, but all of these test cases are now linked to one another. Ideally, all of our tests cases would be completely independent and 100% clear as to what they are trying to accomplish. Is there a reason that you're against normalizing test cases?