Add auxiliary extensible params and state

[sethrj]

For #886 it would be good to start storing state data alongside the core state rather than using the hacky stream store to make the params class mutable.

• Params classes (e.g. actions) can inherit from UserParamsInterface
• UserParamsInterface has a function for the params to create a state (it can be called multiple times with a memspace, stream ID, and size)
• A UserParamsRegistry holds an array of user params, each associated with a UserId
• A UserStateVec is created alongside the core state and it holds the stream-local state corresponding to each user params
• A UserStateData helper class can wrap a FooStateData (collection group)
• A get helper function for getting states from a user

A follow-up PR refactors the optical data using this new change set.

Closes #392 .

---

Non-critical follow-on work: how to combine and output params data with the results of multiple states. Currently the states are unique pointers owned by the core state and created when we build the stepper, and outputs are usually shared pointers that are registered when the params are created. Maybe we should punt on the output for now (so we can get this into the optical state) and consider having a separate "multithread output" class, or using actions to integrate over the streams at the end of a run, or something...

The action diagnostic execution kernel looks like this:

void ActionDiagnostic::execute(CoreParams const& params,
                               CoreStateHost& state) const
{
    auto execute = make_active_track_executor(
        params.ptr<MemSpace::native>(),
        state.ptr(),
        detail::ActionDiagnosticExecutor{
            this->ref<MemSpace::native>(),
            state.user_state_data<ParticleTallyStateData>(user_id_)});
    return launch_action(*this, params, state, execute);
}