Support dot-path as full name for Namespace

It is possible (according to plan but not implemented) to specify the name of a namespace using a dot-separated path with the same meaning as nesting nodes in YAML.

Example:

```yaml
namespaces:
- name: A
namespaces:
- name: B
namespaces:
- name: C
methods: ...
properties: ...
```
can be written equivalently like this:
```yaml
namespaces:
- name: A.B.C
methods: ...
properties: ...
```
(and also this is equivalent):
```yaml
namespaces:
- name: A
namespaces:
- name: B.C
methods: ...
properties: ...
```

This is not yet implemented.

The tasks of this ticket are:
- Update the documentation (if necessary) to reflect this correctly
- Ensure the feature is implemented in _each_ generation tool
- Include appropriate unit tests that show the implementation working
- The unit tests shall be implemented as follows:
Introduce a new reusable test setup. The new test type shall search in a test directory for multiple test inputs and run each of them. This is similar to how the current test is set up. The new test categori shall however specify _two_ IFEX core IDL trees as input (compared to the current tests that have one input and one expected output).
The new test type shall compare and ensure that the output is equivalent for the two trees (otherwise display the difference). It must run multiple types of generations and use every generation tool, to check each pair of inputs, with each of the tools.

Comment:
We ought to already test correct Namespace output for one of the cases in _other_ unit tests, and therefore this equivalence-comparison is enough to prove the feature. The infrastructure for the new test type can however be reused to compare other possible equivalent ways of writing.

Start by locating the current unit-test setup, the generation tools, and the code that handles Namespace names. Compare the nested and dot-path YAML inputs across every generation tool using the proposed reusable equivalence test infrastructure. Done means the outputs are equivalent for all tools, with appropriate unit tests and any needed documentation updates.

Written by the indexing model from the issue text.