Create a framework for matching models to samplers about aemcmc HOT 1 CLOSED

After merging #28 we'll be in a situation where work on this can get started. The situation is still extremely simple right now and is primarily motivated by a need to simplify the current and very redundant "matching" for the supported negative-binomial samplers.

Currently, each negative-binomial sampler step is addressing a distinct part of a somewhat generalized negative-binomial regression model, but it's doing so in an overly rigid and piecemeal fashion. We need to make the logic of each distinct sampling step as independent and "reusable" as possible, and then add a means of incrementally identifying sample steps for each component in a model.

For example, we shouldn't need <model>_match and <model>_gibbs functions that just match/sample expansions/elaborations of essentially the same form of model(s). We don't want to have to write such functions for a negative-binomial model with a fixed dispersion term and one with a non-fixed dispersion term. Instead, we need to walk graphs and determine when/if sub-graphs match an implemented sample step, and, as a result, arrive at the kinds of combinations of sample steps that we currently have.

One basic requirement is a mapping between (sub-)model graph structures and their sample steps. At the moment, we could use the sub-graph "templates" that are used for unification (e.g. the etuples used in nbinom_horseshoe_match) as keys in a map to their corresponding sample step constructors (e.g. nbinom_horseshoe_gibbs). In other words, we can build a DB-like "index" out of the forms used for unification, and perhaps even find a fairly efficient approach for such unifications—e.g. similar to what's done in kanren.facts.Relation.

There are two ways we can approach this and leverage existing code:

1. If we use kanren for the graph walking, then things like multiple-results handling, Relations, and some aspects of condition-checking + unification (e.g. constraints/disequality) are all immediately available; however, some basic aspects of the graph relations aren't very scalable and would need to be addressed almost immediately.

2. If we use Aesara's graph rewriting framework, then we might have a more scalable approach; however, we would need to implement support for generating multiple rewrite results and the aforementioned "index"-like matching capabilities. As well, the relational framework would not be available, which means that we would still be reimplementing aspects of the relations we're ultimately using (e.g. applying one "direction" of an equality in one place and the opposite in another).

from aemcmc.