OpamFilter: handle converted variables correctly when no_undef_expand is true

[timbertson]

Currently it returns the unconverted value when no_undef_expand is true, which means that lwt:enable gets rendered as "true"/"false", not "enable" / "disable". This PR applies conversions if there is some value which can be cast to a boolean.

I don't think this affects end users at all, I discovered this behaviour by using OpamFilter.expand_string ~partial:true directly.

[AltGr]

Well spotted, thanks !

For a bit of context, partial evaluation is used first for all user-variables, but some variables remain to be resolved later because their value depend on the context (e.g. the post flag needs to be manipulated by the solver). I guess this didn't break things because we always end up with a non-partial resolution, but it may have led to extra work.

[timbertson]

Yep, that makes sense. In my case I'm (attempting) to use this to half-resolve build + install instructions, for opam2nix.

That is, things like foo:enabled will be resolved and baked in as simple strings because that information is known from the result of a solve, but prefix and other path variables can't be known until build-time. When it comes to actually building, I'm using a more primitive variable substitution to resolve all the remaining path-related variables.

Hopefully that's a reasonable (if uncommon) use of this feature.

[rjbou]

Thanks!