interpreter: add FeatureOption.enable_if and .disable_if

This adds two new methods, that are conceptually related in the same way
that `enable_auto_if` and `disable_auto_if` are. They are different
however, in that they will always replace an `auto` value with an
`enabled` or `disabled` value, or error if the feature is in the
opposite state (calling `feature(disabled).enable_if(true)`, for
example). This matters when the feature will be passed to
dependency(required : …)`, which has different behavior when passed an
enabled feature than an auto one.

The `disable_if` method will be controversial, I'm sure, since it
can be expressed via `feature.require()` (`feature.require(not
condition) == feature.disable_if(condition)`). I have two defences of
this:

1) `feature.require` is difficult to reason about, I would expect
   require to be equivalent to `feature.enable_if(condition)`, not to
   `feature.disable_if(not condition)`.
2) mixing `enable_if` and `disable_if` in the same call chain is much
   clearer than mixing `require` and `enable_if`:
   ```meson
   get_option('feat') \
     .enable_if(foo) \
     .disable_if(bar) \
     .enable_if(opt)
   ```
   vs
   ```meson
   get_option('feat') \
     .enable_if(foo) \
     .require(not bar) \
     .enable_if(opt)
   ```
   In the first chain it's immediately obvious what is happening, in the
   second, not so much, especially if you're not familiar with what
   `require` means.

0 files changed, 0 insertions, 0 deletions