Remove `IgnoreCommandParameter`

[jgersti]

This PR introduces the following changes:

• Introduce new command parameters for to (AbsoluteCommandParameter) and in (InCommandParameter). All other tokens that are currently ignored can then be discarded before even invoking the actual parser. This allows removal of the rule that discards IgnoreCommandParamter and IgnoreCommandParameter itself.
• Modify the rule for VariableIncrementParameter to include a optional RelativeCommmandParameter (by). This allows removal of the rule that discards RelativeCommandParameter.
• Modify the rule for IteratorComandParameter to include a optional InCommandParameter. Modify the rules that produce PropertySupplierCommandParameters to include a optional InCommnadParameter (in) to the left in case of the rule for PropertyCommandParameter and to the right in case of the rules for ValuePropertyCommandParameter. This handles all cases where in is used inside the test.
• ~~Add a rule to discard AbsoluteCommandParameter before the BlockCommandParameter rule. This is a temporary measure to keep everything running for now . To resolve this the BlockCommandParameter rule most likley needs to be split into seperate cases for assignment and increment/increase. All the assignment rules either before or after the BlockCommandParameter need to be changed to consume a AbsoluteCommandParameter~~ Add AbsoluteCommnadParameters to various rules and do not discard it as a standalone CP.

Changes not yet included are:

• Introduce a IdentifierCommandParameter to simplify/remove CanConvert with checks like name.GetValue().value is AmbiguousStringVariable. Added. see below
• Replacement of ParenethesisProcessor, ListProcessor and MultiListProcessor with conventional rules. This might need some changes to the parser itself like a non consuming lookahead processor.
• Match processors for a rules in order of the defintion instead of unorderd. Currently any rule that matches more than one processor to the left or to the right can match these in any order and the preferred order of the left matches is also reversed. Atleast BlockCommandProcessor and the rules for item transfer (?) depend on this behaviour. As a first step add a paramter to RuleProcessor that allows to select the desired behaviour and determine how many rules depend on the old behaviour.

As a side note : I would propose to rename *CommandParameter => *Token, *DataProcessor => *Match and the current Token => Lexeme. And maybe also renaming a few files to reflect what they contain ParameterParser.cs => Lexer.cs, ProcessingEngine.cs => Parser.cs

_edit:

7. April: updated some points above_

[jgersti]

Move the detection of Primitives into ParseCommandParameter(...) This commit disallows the usage of tokenized primitves as selectors and function names. The changed behaviour should only be noticeable if the predefined color names where used since hex colors, vectors and numbers should not be used as identifiers anyway.

Add IdentifierCommandParameter This commit replaces all VariableCommandParameters which contain an AmbiguousStringVariable where only the string value is used with an IdentifierCommandParameter.
The first rule in branches for AmbiguousSelector is currently unnecessary. If an implicit (unquoted) string can never be an implicit (ambiguous) selector this rule will never used. All implict AmbiguousStringCommandParameters have an empty token list and can therefore never be an AmbiguousSelector (because no block type can be inferred).

[jgersti]

Add AbsoluteCommandParameters to various rules and ... This commit removes the rule that discards AbsoluteCommandParameter. Any rule that needs to be aware of this has been changed to include an data processor that reads AbsoluteCommandParameter.

This commit is more a quick fix and not proper solution since BlockCommandProcessor now matches even more patterns (50+ million assuming only up to 2 assignment matches).

[MerlinofMines]

Multi-Word property support has some conflicts with this one, going in a different direction in order to support "To" separation.

closing this draft for now; we can revisit later.