Should support user-defined joints in libsdformat

[EricCousineau-TRI]

Came up in: RobotLocomotion/drake#12404

For things that are nominally enumerated, add a USER_DEFINED enum, with the ability to access the raw XML... but only when it's a namespaced type? e.g. //joint/@type="drake:bushing"

From Asana, 2019-11-07

[EricCousineau-TRI]

Per f2f with @scpeters, @azeey, and @sammy-tri:

• No concrete use case yet for libsdformat to have a custom joint type
• If/when needed, still need to decide between <joint type="custom:drake:bushing"/> or <drake:joint type="bushing"/>
  • Decision should be motivated by simplicity, e.g. to ensure frame graph can be parsed, libsdformat should know how to get pose + frame name from joint for implicit frame. (Easy if <joint/> is used, needs custom reg if <drake:joint/> is used)
• Failure mode: Some cases don't care if the joint can't be parsed (e.g. Rviz, you just want frames + visuals), while others should really fail fast (e.g. Gazebo simulation, Drake kinematics, etc.)
• Provide guidance on redundancy - e.g. custom joint types should avoid the same types (e.g. revolute) that are already provided by sdformat

[EricCousineau-TRI]

There now seems to be a use case for Drake: planar joints
RobotLocomotion/drake#13747

FYI @SeanCurtis-TRI

[EricCousineau-TRI]

Rescoped to just joints.

Relates #138

[EricCousineau-TRI]

From meeting via VC:

• SC: Schema validation
  * Enumerating joint types for accept //joint/@type
  * Alternative: //joint/@type="custom"

<!-- Option (1) -->
<joint type="custom">
<drake:joint_type>planar</drake:joint_type>
</joint>

<!-- Option (2) -->
<joint type="custom" drake:type="planar">
...
</joint>

<!-- Option (3) - hell nah -->
<drake:joint name="my_joint" ...>
<pose relative_to="..."/>
</drake>

<link>
<pose relative_to="my_joint"/>
</link>

* How can custom schemas can be validated?

[EricCousineau-TRI]

This should be scribed into a proposal, along with API as mentioned in #329

[EricCousineau-TRI]

From conversation in gazebosim/sdf_tutorials#45, I believe we've reinforced that the ultimate solution should be //joint/@type="custom". It should be either like Option (1) or Option (2), which is up to the downstream library.

I'm going to take Option (3) out of the running.

FYI @SeanCurtis-TRI @joemasterjohn