[WIP] Add support for dynamic match policy changes and always use first match for feasibility/satisfiability

[milroy]

This PR adds support for dynamically changing the match policy based on a jobspec or other conditions. It also configures the first match policy to be used for satisfiability/feasibility checks to improve performance.

This PR addresses but likely does not completely solve the satisfiability/feasibility check performance problem reported in issue #1159. (The system configuration at the time would not have benefited from this change.

[codecov]

Codecov Report

Merging #1160 (4219d35) into master (68c636a) will decrease coverage by 0.1%.
The diff coverage is 89.4%.

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #1160     +/-   ##
========================================
- Coverage    71.0%   71.0%   -0.1%     
========================================
  Files          96      96             
  Lines       12867   12875      +8     
========================================
+ Hits         9147    9150      +3     
- Misses       3720    3725      +5     

Files	Coverage Δ
resource/traversers/dfu.cpp	87.5% <100.0%> (-0.2%)	⬇️
resource/traversers/dfu_impl.hpp	94.7% <ø> (ø)
resource/traversers/dfu_impl.cpp	82.9% <80.0%> (-0.1%)	⬇️

... and 4 files with indirect coverage changes

[vsoch]

Potential use cases for this:

• Folks are asking about (and wanting demonstration for) this capability in the hpc.social slack
• In that same thread, I'd like to do a Flux tutorial that demonstrates it working
• We would very much find this useful for Kubernetes environments in a custom scheduler plugin.

Some points we talked about:

• On a super large cluster, if a user submits a custom jobspec that takes 1 minute to match, this could hugely disrupt the cluster. Likely we'd want a way to disable it, system wide, and possibly have a whitelist policy.
• If not done via an official change to jobspec (unlikely to happen soon) we can pass forward some preference another way (attributes, for example).

@trws did you ever look at this PR and did you have any thoughts? I'd like to push on it, given the above, even if we have something that isn't part of core, but something that can be exposed another way. Thank you!