Add option to keep instance information

[erikbosch]

As of today all our tools expand instance information, resulting in that you do not know (for sure) if Row1 represents an instance or is a real branch. In some cases, like for example if you want to create an object oriented API/SDK this might be a disadvantage as you may want to offer methods like:

is_my_door_open = my_vehicle.getDoor(ROW1, DRIVER_SIDE).is_open()

... rather than having Row1 and DriverSide as objects. Having a JSON file where no transformation/expansion has been performed make it easier to generate the API/SDK as wanted. Under the hood the API/SDK must still create the old expanded path if it is to communicate with an implementation that rely on trditional expanded paths (like VISS and KUKSA.val)

The implementation in this PR add functionality for Yaml, JSON and CSV exporters. For others a warning is given if --no-expand is used. See test cases for examples.

The included *.json file on top level is only for reference and will not be part of final commit. It shows resulting JSON if using latest VSS and the --no-expand option.

[erikbosch]

Meeting notes:

• Erik presented the ideas.
• Please review/discuss

[BjoernAtBosch]

Disadvantages would be:

• The detection of instances is possible, in principle. But it requires extra effort.
• The detection might face some limits, when it comes to instances that contain attributes or signals valid for that single instance (or more precisely: a limited set of instances), only
• Digital.Auto is using a json-based VSS catalogue which is "not aware" of instances. There, the "expanded" attribute would need to be maintained manually, which probably leads to additional error cases.

[BjoernAtBosch]

This then would be a "mixed" solution?
Means, expanded instances plus original instance information?

[erikbosch]

Yes, some form of mixed solution.

[BjoernAtBosch]

I think, this would be our (Eclipse Velocitas') favorite solution, because with that the generated files (json, ...) become semantically identical (except file structure) to the original vspec.

I also tested this with our code generator and it works fine.

[BjoernAtBosch]

We (Velocitas) also need to discuss with Digital.Auto, what they think/prefer.

[erikbosch]

Meeting notes:

• Sebastian: How would overlays work, adding a signal for a specific instance
• Please review

[erikbosch]

Added test examples on how this works with overlays. In short, using our overlay mechanism to add signals to expanded paths works, but then the consumer of the output need to do the logic understanding that Vehicle.Door.Row1.Pos1.NewSignal actually refer to the signal Vehicle.Door.NewSignal in the door instance Row1.Pos1.

That is likely Ok for now, but perhaps as part ongoing VSS discussions (this one, ontologies, ...) we possibly need to refactor how we define and use instances, like discussed in COVESA/vehicle_signal_specification#642.

[erikbosch]

Meeting notes:

• Erik: Proposal - document limitation "individual instances in overlays" and the merge
• ok