Substitute physics-engine-specific elements with generic ones

The [``](http://sdformat.org/spec?ver=1.7&elem=physics#physics_dart) element currently supports tags that are physics-engine specific (``, ``, ``, ``). These tags apply to Gazebo classic, but they don't necessarily work for other simulators using SDFormat. For that reason, I think we should deprecate these tags and work on a more generic and extensible spec.

It's important we decide this before we add C++ "DOM" classes to access these elements.

## Desired behavior

Users can set parameters under the `` tag, and each simulator / physics engine supports them as possible. This is similar to how most other tags are handled. For example, the spec has a `` that not every engine may support, and that's ok.

## Alternatives considered

We could keep adding tags specific to every physics engine to the spec, but that doesn't scale well, and ultimately forces the end user to configure various settings for each engine, sometimes repeating themselves.

## Implementation suggestion

### Promoting elements to be generic

One quick implementation would be to pull all elements that are currently nested under specific engines one level higher, so they're direct children of ``. So for example, instead of:

```

some dart solver


some bullet solver

```

We could have a pattern like this, where each engine picks the first option that works for them:

```

some dart solver
some bullet solver

```
### Accepting arbitrary key / values

Another alternative is to offer an interface that's a bit more open-ended and accepts arbitrary key / value pairs. For example:

```

```

From the C++ API, these could be accessible as a map with an `std::string` as key and a `ParamVariant` as value:

https://github.com/osrf/sdformat/blob/9c4261badf4fff56fb29da74e0eaa53eaf3cb31e/include/sdf/Param.hh#L244-L254

This option could make the spec more flexible, but it may go against the purpose of having a spec in the first place. If any simulator can accept any parameters they want, we may quickly end up with Simulator A accepting `solver_type` and Simulator B accepting `type`, and users needing to set all variations to make their worlds portable.

### Custom elements

SDFormat now accepts custom elements, as described on [Custom elements and attributes](http://sdformat.org/tutorials?tut=custom_elements_attributes_proposal&cat=pose_semantics_docs&). Each simulator / physics engine could use these to specify tags that are specific to them. For example:

```

some dart solver
some bullet solver

```

Similar to the key / value approach above, this may offer too much flexibility. Unlike that approach, it may be difficult to come up with a C++ API for them, since custom elements are meant to be ignored by SDFormat.

### Conclusion

I believe we may end up with a combination of the options above. I'm leaning towards bumping some of the most common parameters to first-class `` elements, and providing a `` API where engines can put parameters that are very specific to them.

## Additional context

This issue is analogous to https://github.com/osrf/sdformat/issues/31 for friction.