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.

> What do you think about bcwaldon@740f99e

It's alright, it just seems like a tiny step from `makeFleetOption` to `makeXConflictsOption`. It's all a bit grey in the middle here `¯\_(ツ)_/¯`