Remove support for externally-provided scalar types

[jwnimmer-tri]

This issue proposes to remove support for downstream-defined scalar types.

Many classes in Drake are templated on the type of numerical Scalar used for computation (e.g., double, AutoDiffXd, symbolic::Expression), usually denoted by template argument <T>.

We have https://github.com/RobotLocomotion/drake/blob/master/common/default_scalars.h which defines the typical scalars used within Drake, and provides macros to declare and define template instantiations across those types.

Some code in Drake (e.g., multibody, primitives) places most method definitions into cc files, which means that even though the class is templated, the permitted values for <T> are closed off to be only the default scalars and nothing else. Other code in Drake (framework) places method definitions in header files so that the set of valid <T> is open -- any real-number-like type can be used.

I propose that we switch all code in Drake to use the former pattern -- only support the default scalars.

This will allow us to move most method definitions to cc files instead of headers. (Code where inlining is important for performance would not move, nor would code that is templated on user-provided types such as MySystem or MyBasicVector.) That should substantially improve compile times, both inside Drake and for downstream users.

If we find good cause for scalars beyond the current defaults (e.g., #12019), we can add them to default_scalars.

If any Drake users need new scalars, please post below with details.

---

Edit: Added task checklist:

• [x] systems/framework/context (#13842)
• [x] systems/framework/continuous_state (#13844)
• [x] systems/framework/diagram (#12852)
• [x] systems/framework/diagram_builder (#13866)
• [x] systems/framework/diagram_context (#13842)
• [x] systems/framework/diagram_continuous_state (#13844)
• [ ] systems/framework/diagram_discrete_values
• [ ] systems/framework/diagram_output_port
• [x] systems/framework/diagram_state (#13844)
• [ ] systems/framework/discrete_values
• [ ] systems/framework/event_collection
• [x] systems/framework/leaf_context (#13842)
• [x] systems/framework/leaf_system (#12816)
• [ ] systems/framework/single_output_vector_source
• [x] systems/framework/state (#13844)
• [x] systems/framework/system (#12913)
• [ ] systems/framework/subvector
• [ ] systems/framework/supervector
• [ ] systems/framework/system_base (could be improved)
• [ ] systems/framework/vector_system

[edrumwri]

+1 on this- I would definitely trade a little bit of inflexibility in adding new scalar types for much faster compilation times.

[RussTedrake]

The two highest potential scalar types not currently in the default scalars, in my mind, are probably:

• higher derivatives in autodiff.
• chunking autodiff (#2619, much discussed, but never PR'd). I understand your proposal is that we would add them to default scalars if/when we need them. But higher derivatives, in particular, feel like a case where I would only want to add them (to a particular order) if I had a specific use case for them...?

I still might trade compile time for features, but just want to think it through.

[jwnimmer-tri]

The challenge is that its difficult to incrementaly add a new scalar for just one specific use case to only the places its needed. Even leaf_system uses 149 source files in Drake (of course not all of them are templated on scalars), or //systems/primitives needs 261 files in total. Trying to add the new scalar one by one to all of the dependencies of some smaller example will end up death by a thousand cuts. For the core libraries at least, an agreed-upon common set of scalars seems like the correct trade-off. Code can opt-out of autodiff or symbolic or some-new-scalar like we do now, in cases where it doesn't make sense.

[RussTedrake]

In this case, it sounds like we effectively do not currently support externally-provided scalar types and having nothing to lose. SGTM.