Specify behavior of setting "incompatible" Features in a Target

[steven-johnson]

If you set an "incompatible" Feature on a Target, it's not clear that the resulting behavior is well-defined. For instance, say I try to compile using a Target of "arm-64-android-avx" -- what behavior should we expect? Among them:

(1) Should Target::from_string()/merge_string() detect impossible combinations and return false, or just quietly assemble the resulting Target?
(2) Should attempting to compile/JIT/etc with such a Target fail outright, or just quietly ignore inappropriate features?

AFAICT, both of these take the "else" case above; if that's explicitly desired, we should document and test that behavior.

[alexreinking]

Some discussion was held in #3671. Now, when computing a runtime target from multiple targets, features that must match across all targets are validated.

Ideally, we would define a sort of "algebra" of targets: define well-formedness of a target, how to merge, how to edit, etc. Then we would implement these things explicitly on the target class and could remove code duplication between Target.cpp and Module.cpp

[abadams]

Will be fixed by #9251