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);
}

[esseivaju]

Nice! LGTM, just a few minor comments.

[esseivaju]

Same here, is the out-of-line definition needed?

[amandalund]

This looks great, thanks @sethrj! The only thing I'm a little unsure about is the name User; it definitely fits for the diagnostics, but maybe not as much when we're using this for the optical data.

[amandalund]

A couple Users left (in case you want to replace them in #1280).

[amandalund]

Suggested change

	using SPUserRegistry = std::shared_ptr<AuxParamsRegistry>;
	using SPAuxRegistry = std::shared_ptr<AuxParamsRegistry>;

[amandalund]

Suggested change

	using SPUserRegistry = SP<AuxParamsRegistry>;
	using SPAuxRegistry = SP<AuxParamsRegistry>;