feature: remove limitations on [enabled_if] on libraries

[rgrinberg]

Previously, the enabled_if field on libraries had a bunch of limitations. Basically, only variables that could be computed from the context could be used. E.g. profile, context_name, etc. This PR removes this limitation and now every variable is allowed provided that it doesn't introduce a memoization cycle.

Normally, such a feature would be trivial, but here we some module dependency cycles that prevent the natural solution from working. If it was possible, we would just call Super_context.expander ~dir sctx |> Expander.eval_blang everywhere and be done with it. Unfortunately, we have to solve two problems:

1. Expander depends on scope, and we need enabled_if to compute the scope
2. Super_context depends on scope, and therefore on various enabled_if through 1.

So we break this cycle by introducing an Expander0.t that doesn't depend on scope and has an expander db that is the equivalent of Super_context.expander.

[rgrinberg]

@jchavarri since you've expressed interest in this PR and have looked at this code lately, I've added you as a reviewer. I've also improved the description of the implementation.

[jchavarri]

I asked some questions, mostly trying to follow what's going on. Probably this change needs a changelog entry.

So we break this cycle by introducing an Expander0.t that doesn't depend on scope and has an expander db that is the equivalent of Super_context.expander.

I took a look at removing the cycle by moving lookup_artifacts out of Expander, but more cycles surfaced:

Error: Dependency cycle between:          
   _build/default/src/dune_rules/.dune_rules.objs/dune_rules__Scope.intf.all-deps
-> _build/default/src/dune_rules/.dune_rules.objs/dune_rules__Expander.intf.all-deps
-> _build/default/src/dune_rules/.dune_rules.objs/dune_rules__Library.intf.all-deps
-> _build/default/src/dune_rules/.dune_rules.objs/dune_rules__Library_redirect.intf.all-deps
-> _build/default/src/dune_rules/.dune_rules.objs/dune_rules__Deprecated_library_name.intf.all-deps
-> _build/default/src/dune_rules/.dune_rules.objs/dune_rules__Scope.intf.all-deps

I wonder if it'd be worth exploring that path more, as increasing the amount of code in Expander0 seems like a short term solution rather than something maintainable in the long term to me? Probably this feeling comes from code duplication and new state being added in set_db, which I understand could lead to situations where Expander and Expander0 could get "out of sync".

[rgrinberg]

I asked some questions, mostly trying to follow what's going on. Probably this change needs a changelog entry.

So we break this cycle by introducing an Expander0.t that doesn't depend on scope and has an expander db that is the equivalent of Super_context.expander.

I took a look at removing the cycle by moving lookup_artifacts out of Expander, but more cycles surfaced:

..

I wonder if it'd be worth exploring that path more, as increasing the amount of code in Expander0 seems like a short term solution rather than something maintainable in the long term to me? Probably this feeling comes from code duplication and new state being added in set_db, which I understand could lead to situations where Expander and Expander0 could get "out of sync".

You can try exploring it, but there are fundamental issues here that make it impossible to factor our code enough to prevent cycles. There's three different concerns:

1. Expanding a percent form - adds a dependency on the public API of the expander (pforms, templates, projects, etc)
2. Implementing an expander - requires knowing all the types of data that can exist inside an expander (scopes, artifacts, etc)
3. Constructing a percent form - requires knowing how to make an expander and populate it with data. The data can come from just about everywhere (super_context, env_node, dir_contents, etc)

You can see how steps 2. and 3. are limiting. Anytime you want to expand something, pulling in 2 or 3 might not be an option.
So in the end we do need a way to expand things with only 1.

Another thing we can try is to pass an expansion function around to those that need to expand. That ends up creating a bunch of inconsistency bugs because this exapnsion function is being constructed in a slightly different way everywhere.