Add environment element at boards and components level

[silviooliva]

The environment element is used in the standard at device and part level.
It may contains child elements that are specific for a development tool (identified by the environment's attribute name). The structure of an element inside the environment is not specified in the xsd schema file, which gives the development tool full control of the element usage.

So far, the environment can be used in elements:
/package/devices/family
/package/devices/family/device
/package/devices/family/device/variant
/package/devices/family/subfamily
/package/devices/family/subfamily/device
/package/devices/family/subfamily/device/variant
/package/parts/part

To me, it should be introduced also at boards and components level since, also for these elements, there could be the need to define some tool-specific information.

So my proposal is to extend the standard introducing the environment as (optional) child element of the following elements:
/package/components/bundle
/package/components/bundle/component
/package/components/component
/package/boards/board

[silviooliva]

@jkrech, @ReinhardKeil, what do you think?
The modification should enhance the standard. If you are ok with that, I can take charge of opening the PR.

[jkrech]

@silviooliva, thanks for the systematic review of the tag. Adding more places for environment specific information adds flexibility to capture additional tool dependent meta information in the package description.
My worry still is that despite us wanting to specify a standard format we end up with a level of flexibility which will make packs unusable in tools which will ignore this meta information.

[silviooliva]

@jkrech, I understand your concern, even if the presence of the mandatory elements (and their mandatory attributes) in the standard should provide the set of information ensuring that a pack is working in tools ignoring the meta information.
On the other hand, having such meta information through the environment element should favor the increase of the number of tools using the Open-CMSIS packs, so making the standard more and more popular.

[mdortel-stm]

@jkrech I get your concern.
As @silviooliva said, giving flexibility should open doors for newcomers.

Up to each tool owner to check the reusability of its own packs. But let's say that, even if a pack becomes "not portable", it gives at least visibility for the standard.

In other words, as long as the standard is not able to cover all specificities, we need those entry points to keep using it. At least that's my feeling.
Maybe time will bring solutions to replace those tool defined items, or they will keep that form because they are real corner cases that a standard should not try to cover. Universality is quite hard to reach 😊

[jkrech]

Understood. @silviooliva I did not mean to say that you should not prepare the PR adding environment more systematically throughout the hierarchy of the description.
I certainly prefer an environment tag being used instead of 'abusing' elements intended for other purposes.

[jkrech]

@silviooliva: Thanks for the PR. We had previously added <extensions> to <component> upon STMicroelectronic's request.

1. June 2022: v1.7.8
   - added extension points description for components as suggested by STMicroelectronics

Are we certain we need both?