Fully support choice only models

[AlexanderFengler]

We are currently working through a refactor that will introduce a HSSMBase class which both the current HSSM and the new HSSMRL classes are supposed to inherit from.

Especially for the HSSMRL class we already worked through the definition of composable model configs that combine a learning_process with a decision_process.

A long-standing "special case" of what we are doing are models that concern themselves only with p(choice|theta, X) and ignore rts.

The time is ripe now to address this and benefit from the emerging rl capabilities in one go.

Proposal:

We need the following steps,

1. basic implementation of a softmax likelihood in pytensor/jax (very easy) with associated model config (include proposal on how to signify a likelihood as choice only)
2. create new or just generalize current likelihood constructors to accept data that has only (theta_1, ..., theta_n, choice) inputs (this is a question of adjusting some of the dimensionality expectations. Note, we already have capability for choice probability networks, definitely take a look at that, it should be very reusable and informative.
3. inherit from base class, and make a HSSCM class that deals with choice only models. Fiddle around with it until the basic softmax model works. The key will be some adjustments to the data validators and requesting the right underlying likelihood constructors. Otherwise it should be relatively straight forward.
4. incorporate utilization of choice probability networks where they are available for a given model (this infrastructure will need to be fleshed out by adding more huggingface models). So if the user request e.g. angle model to the HSSCM class, we check if there is a "choice only" version of the likelihood available, if not throw error.
5. Expand to HSSCMRL class, which connects choice only models to RL processes. This should be quite straight forward, at that point, because we already figured out all key pieces.

@krishnbera @digicosmos86 @cpaniaguam

[digicosmos86]

Thanks @AlexanderFengler! For my own understanding, is there anything special other than dimensionality requirements that would require a separate class? I would be very careful about branching out new classes because we are potentially dealing with exponential growth of numbers of classes here

[digicosmos86]

Another thought: we also have the response field in ModelConfig, so we can add a method to it named is_choice_only, and we can use it for validation. In terms of likelihoods, they will always have the signature logp(data, *dist_params), where data can be however many columns we want. So I think our current code will still work without much modification, unless there is something significantly different that I didn't know about

[krishnbera]

Once the RLSSM module is ready for testing, I can test the basic RL model with choice function (implemented in JAX).
Infact, we already have the implementation as part of the RLWM likelihood.