feat: allow dash as ID_STRICT for imports

[MiriamGaus]

fixes #56

[SundermannC]

Thanks a lot for your PR and all your contributions to UVL over the last months in general @MiriamGaus!
This is very much appreciated.
I think this particular change may cause ambiguities. We suppressed all allowed arithmetic operators in non-enclosed feature names to prevent the ambiguity between having a two features connected by an operator (without spaces) and a single reference. I have not tested it yet but the expression in the constraint below should be parsed to the non-existing feature with the name "A-B", which may not be intended. Maybe it would be fine to enforce spaces between the feature names. Maybe we could also enable the non-strict ids with "import-name" in imports? What do you think?

features
     Root
       optional
           Integer A
           Integer B
constraints
     A-B == 0

[MiriamGaus]

You're right. The given model isn't parsed, although it should be possible to parse. With enforcing spaces there is no ambiguity anymore. I'm not sure whether this is a wanted solution. Even though spaces provide a better readability for the constraints.
I think non-strict ids don't fix the problem because if there is no alias enforced the dash remains in the identifier and causes the same ambiguity problems.

[SundermannC]

I am not sure about enforcing spaces as well. I do not hate it in general, but it would probably require more substantial changes in the way we parse.
Regarding non-strict ids, also enforcing " ", just as we do for features, should work right? Or is there an issue I am missing?
For example, allowing the following should resolve the issue, right?

imports
    "name-with-dash"

features
   "name-with-dash".Root

[MiriamGaus]

I think this could fix the issue, I tried it and this already works. This should be added to the documentation.
Another solution could be to enforce an alias without a dash in it. This should fix the problem as well.
Is it okay to change the semantics of the UVL parser? For example to your given solution.

[SundermannC]

I am heavily in favor of applying your proposed change, but I also think we should be generally cautious when changing the semantics of the language/ the base parser. We should probably get feedback of more involved parties on this prior to merging.

Edit: I just understood that this required no change to the grammar at all. Then, I think we can merge right away.

[SundermannC]

Even though I do not mind this change here, we probably do not want to adapt files for visual structure in unrelated commits in general.

[SundermannC]

Thanks for updating the documentation. Looks good overall, I just have small change requests.

[MiriamGaus]

With the new bigger changes for the uvl parser, this PR becomes irrelevant and can be closed