Merge orders and orderers for CIF data-based synthesis variable ordering

This has been suggested and discussed a bit here:

The idea would be to:

Change variable orders to be variable orderers that produce an order that does not depend on the input order:
- VarOrder.order produces a potentially interleaved variable order, which needs to be possible with VarOrderer then. Some methods to convert a variable order to a list of synthesis variables and such a list to a possibly interleaved variable order, are then needed for variable orderers that don't support interleaved variables. Or make a base class for variable orderers that don't support interleaving. I think I would prefer the latter.
- VarOrderer.order gets an inputOrder argument, while VarOrder.order doesn't. One option is to have the current VarOrder ones just ignore that argument. Another option is to make a derived class of VarOrderer that serves as base class for all current VarOrder implementations, providing the model order as argument, rather than an input order (the current order).
- Currently, to apply an initial order and then some orderers, we have OrdererVarOrder. It creates a new VarOrderHelper based on the initial variable order. Since orders and orderers all become orderers, it is no longer mandatory to start with a predefined order. We can just start with model order, as we do now for the VarOrder instances. These should then create the new VarOrderHelper. This can be done in the new base class, as mentioned in the previous point.
- Since everything becomes an orderer, it would make sense to allow a predefined order to be defined anywhere in a sequence of orderers. Per the previous point, it would create a new VarOrderHelper. As this needs to be passed to the next orderer in the sequence, we need to be able to return more data. We thus need a class to store the variable order and helper that are the result of this orderer and input to the next orderer. We could name it VarOrdererResult.
- Predefined orders will create a new helper, as per the previous point. Currently, this is only done when they are applied as initial order. If they can be applied as a later step in a sequence, we could want to apply them to update the variable order, or the representations in the VarOrderHelper, or both. It would be good if this could be configured. By default, they would do both, to be backward compatible. The base class, see earlier point, could support this, reducing code in the implementations of predefined orders.
- We should replace ReverseVarOrderer by ReverseVarOrder, as the latter handles interleaving of synthesis variables, while the former does not.
Introduce a VarOrder class for variable orders:
- Making all current VarOrder instances become VarOrderer instances, we free up the VarOrder class name to be used for this purpose.
- The new VarOrder class represents potentially interleaved synthesis variables.
- We thus give this type a name rather than being a Pair<List<Pair<SynthesisVariable, Integer>>, String>.
- We may be able to provide some useful constructors and/or methods here as well.
Simplify parser AST class names:
- They are now named VarOrderOrOrderer*.
- They can be named VarOrderer* instead.