Improve conditional components

[HansOlsson]

The current conditional components are problematic to use due to the restrictions on their use. We have customers that use them use them extensively (Dymola previously opted for the first solution for 1 below), and find the current rules problematic.

https://specification.modelica.org/master/class-predefined-types-and-declarations.html#conditional-component-declaration

Specifically there are two different sets of issues:

1. The use of a a conditionally enabled component is prohibitively restricted:
   1. Even if we can prove that the use is conditional under the same (or stricter) conditions for its existence it is still illegal. The example in the specification even contains one such example.
   2. One cannot "transform" a conditional component to a normal one; code below.
2. The use of a conditionally disabled component is limited to connect-statements.

Example of 1.i:

  Level1 component1(J=J) if level==1 "Conditional component";
  Level2 component2 if level==2 "Conditional component";
  Level3 component3(J=component1.J) if level<2 "Conditional component"; // Illegal use of component1.J
  Level4 component4(J=component1.J) if level==1 "Conditional component"; // Illegal use of component1.J

The Level3 case is from the specification. The Level4 case is even simpler (exactly the same condition), and one could even restrict it to a boolean parameter, and use the same boolean parameter.

Example of 1.ii:

 model M
    parameter Boolean isActive=false;
    Real a=time if isActive;
end M;
M m(final isActive=true);
Real x=m.a; // Still illegal, even if final modifier

I see two different solutions for 1:

• We just remove the restriction on conditionally enabled components, and view the stricter checks as a quality-of-implementation check, similarly as balancing-check for other parameter-values than the ones currently used.
• We allow it under some very restrictive, but useful conditions:
  • A conditional component can be used in components with exactly the same conditions, or in other cases if the condition evaluates to true and is based on modifiers that are all final. (Exactly how to formulate this isn't clear - we don't have this concept of "final" all the way, and equality of conditions may not always be simple. It is also unclear how useful this will be; in particular we also need to consider 2 below.)

The solution for 2 will require more care (it may also seem less urgent), as we cannot just remove parts of equations at will. I see two related alternatives:

• One possibility would be follow C++ and have something like if constexpr (x) { (with an evaluable parameter-value condition); and say that conditionally disabled component can be used in such constructs that are not active.
• Another solution would be that it is always allowed in if-statements in equations, and require that their condition in those cases must be an evaluable expression that evaluates to false (if the component is disabled). One issue is that the use can be inside nested if-statements; which makes it unclear which of those if-statements must have an evaluable condition; it that is an issue I think I would prefer if the restriction was for the top-most one.