Add namespace support to SDF elements for easier multi-robot simulation

## Desired behavior
It would be useful if SDFormat could provide native support for a `namespace` field, so that tools and simulators using SDFormat can better support multi-robot simulations.

In multi-robot simulations, users often want to spawn or include multiple instances of the same robot description file (.sdf/.urdf). However, to avoid topic collisions, users usually need to manually modify or template description file (.sdf/.urdf), for example by adding prefixes to topic names, sensor plugin parameters, plugin parameters.

The desired behavior is to allow users to reuse the same robot description file more easily, while still keeping the communication interfaces of each robot isolated.For example, users should be able to include or spawn the same SDF / URDF description file multiple times and assign a different namespace to each instance, without duplicating or heavily modifying the original robot description file.

## Alternatives considered
One possible alternative is to reuse the existing `name` field as the `namespace`. However, I think `name` and `namespace` have different meanings:

- `name`: mainly describes the identity of an entity or system in the simulation.
- `namespace`: describes the **communication scope** used by topics and related interfaces.

Following is an example showing the difference:
``` xml

...

...

```

Another reason is **flexibility**. The `name` field is usually **required**, while `namespace` can be **optional**. Users may not always want every element name to become part of the topic namespace. For example:
```xml

...

...

...

/data
...

```
In this case, the user may want the final camera topic to be `/robot1/camera/data`, instead of `/robot1/sensor/camera/data`

## Implementation suggestion

1. Add an **optional** `namespace` **attribute** to `world`, `model`, `sensor`, and `plugin`

Since `namespace` is similar to `name` in that it describes metadata of the element itself, I think it may be reasonable to define it as an **attribute**. For example:

```xml


Namespace used for communication interfaces related to this element.


```

To avoid making this a breaking change, we could make namespace an **optional attribute** with an **empty default value**.

2. Add an **optional** `namespace` **element** to `include`

For `include`, the design may need to be different from `world`, `model`, `sensor`, and `plugin`. I think it may be better to follow the current `name` **override** style in `include`, and add `namespace` as an **element** inside `include`. For example:

``` xml

model://my_robot
robot1
robot1

```

The `namespace` value in `include` could override the `namespace` of the top-level included `element`.

3. Support a **placeholder** such as `__name__`

In many cases, the desired `namespace` is the same as the `name`. For this common case, it may be useful to support a **placeholder** such as `__name__`, which means “use the final resolved name of this element as the namespace”. For example:

``` xml

...

```

For `ros_gz` users, they could specify only the `entity` name when spawning the robot, and the `namespace` could automatically follow that `name`.

```bash
ros2 run gazebo_ros spawn_entity.py \
-entity robot1 \
-topic robot_description \
```

## Additional context
This idea mainly comes from the `Gazebo` multi-robot simulation use case. The goal is to provide a standard way for SDFormat users and downstream tools to describe communication `namespaces`, so that multiple robot instances can be used with less manual SDF / URDF templating.

I am not fully sure whether this design fits all SDFormat use cases, or whether this should be handled at the SDFormat level.

I would appreciate feedback and advice from maintainers and the community.