Proposal "struct": Extend VSS to model structs

This is basically extending VSS syntax to enable modelling of structs and allowing those structs to be used as "datatypes".

See the example proposed here https://github.com/kkoppolu1/vss-tools/commit/342c94608e48a43df9d8aaf9bf2160391621b931

A proof-of-concept commit that demonstrates how we can use "struct" and "item" keywords to model complex types in VSS.

Example

Vehicle:
    type: branch

Vehicle.ADAS:
    type: branch

Vehicle.ADAS.Lidar:
    type: branch


Vehicle.ADAS.Lidar.ObstacleClass:
    type: struct

Vehicle.ADAS.Lidar.ObstacleClass.Class:
    type: item
    datatype: uint64


Vehicle.ADAS.Lidar.Obstacle:
    type: struct

Vehicle.ADAS.Lidar.Obstacle.Id:
    type: item
    datatype: int64

Vehicle.ADAS.Lidar.Obstacle.Probability:
    type: item
    datatype: float

Vehicle.ADAS.Lidar.Obstacle.Class:
    type: item
    datatype: Vehicle.ADAS.Lidar.ObstacleClass.Class


Vehicle.ADAS.Lidar.ObstacleList:
    type: struct

Vehicle.ADAS.Lidar.ObstacleList.Data:
    type: item
    datatype: Vehicle.ADAS.Lidar.Obstacle[]

Vehicle.ADAS.Lidar.Front:
    type: branch
    
Vehicle.ADAS.Lidar.Front.Obstacles:
    type: sensor
    datatype: Vehicle.ADAS.Lidar.ObstacleList

Example .proto: https://github.com/kkoppolu1/vss-tools/commit/342c94608e48a43df9d8aaf9bf2160391621b931#diff-dbbabee6f305bf66fb34859941c86c269945c5024da29023f3bb7c4949b6fbfe

Example JSON: https://github.com/kkoppolu1/vss-tools/commit/342c94608e48a43df9d8aaf9bf2160391621b931#diff-595fc68dc61acd516dbb940680268c94c924daeb98f81b6dd6474906bce30235

Advantages:

• VSS defines its own primitive types. Extending VSS to support complex/aggregate types is a natural extension of the specification
• The specification is self-contained and does not rely on an external specification integration.
• We have vss-tools that convert vspec to standard specifications such as JSON, protobuf etc. In a similar fashion, we can build tools/parsers to translate from standard IDL formats to vspec.

Disadvantages:

• vspec format already isn't the most user friendly to write, when it gets more complex (also not so many tools supportng you). Maybe this would be more suitable for tool conversion existing idls.
• many open detail questions, even in the example above (is this how you would do arrays in this case? Shoudl the entries in obstacle.vspec have a type?)
• The specification may not be able to model all types possible in other IDLs.
• makes vss-tools more complex and also the effort is somebody where to reimplement them

Open points

Would we really want to inter-mingle datatype definition into the same tree (at least in output) as the VSS data model itself, for example in the example Vehicle.ADAS.Lidar.Front.Obstacles is an element that might be set or queried in an access protocol such as VISS, while the similar looking Vehicle.ADAS.Lidar.Front.ObstacleList is datatype definition, which is conceptually quite different.

This is however, no inherent to the "extend VSS approach", this could probably designed to keep datatype definitions outside the definition of the tree itself as well in input as well as output.

Check https://github.com/COVESA/vehicle_signal_specification/wiki/Proposal-%22struct%22:-Extend-VSS-to-model-structs---Option-2 for a variant of this proposal