Concept for specifying VSS-tools profiles?

A topic that is mentioned now and then is the possibility to add and possibly standardize additional metadata to VSS signals to describe "feature of interest", "safety/security classification", "CAN dbc mapping" and similar. In VSS that is already possible by using extended attributes.

```
Vehicle.Speed
type: sensor
datatype: float
unit: km/h
my_own_attribute_1: 123
my_own_attribute_2: "free text"
```
The tooling supports extended attributes, if you specify `-e my_own_attribute_1 -e my_own_attribute_2` no warnings will be given and the extra attribute will be present in generated files like yaml, csv, json.

I am thinking of two potential "improvements"

**Concept for defining profiles**

To provide better re-usability and control of extended attributes I am thinking if it would make sense to define a profile format, possibly like below. That profile could be loaded by vss-tools and be used to validate signals in the catalog. That could be useful if you for a particular deployment need to provide some extended attributes for every signal.

```
myprofile:
mandatory: true # If true all signals must use this profile, so they must have "my_own_attribute_1"
my_own_attribute_1:
mandatory: true
unit: uint16
description: "Describes xxxxx"
my_own_attribute_2:
mandatory: false
unit: string
description: "Describes xxxxx"
```

This could then be added as input to vspec

`vspec export csv -p /some/path/to/myprofile.yaml`

**Managing a catalog of profiles**

It would be possible for VSS (or VSS-tools) repo to host a folder with contributed and/or recommended profiles. I.e. if a COVESA member or a downstream project has defined a profile they think is generally useful, then it could be contributed to COVESA so that also other downstream solutions could use it.

Note that the profile catalog would only define the extended attributes that are possible to use, it would (most likely) not provide actual values to use for the signals in VSS Standard catalog as that would differ from case to case.

Start with the existing extended-attribute support in vss-tools and the `vspec export csv -p /some/path/to/myprofile.yaml` entry point. Clarify the profile format, validation rules, and how a contributed profile catalog should work. Done means the agreed profile concept is specified well enough to validate catalog signals and define reusable extended attributes.

Written by the indexing model from the issue text.