Implement several RandomVariables as SymbolicRandomVariables

[ricardoV94]

Description

Implement several RandomVariables as SymbolicRandomVariables

This allows sampling from multiple backends without having to dispatch for each one

Also:

• Allow signature to handle rng and size arguments explicitly.
• Move rv_op method to the SymbolicRandomVariable class and get rid of dummy inputs logic (it was needed in previous versions of PyTensor)
• Allow dispatch methods without filtering of inputs for SymbolicRandomVariable distributions

Related Issue

• [ ] Closes #
• [ ] Related to #

Checklist

• [x] Checked that the pre-commit linting/style checks pass
• [x] Included tests that prove the fix is effective or that the new feature works
• [x] Added necessary documentation (docstrings and/or example notebooks)
• [x] If you are a pro: each commit corresponds to a relevant logical change

Type of change

• [x] New feature / enhancement
• [ ] Bug fix
• [ ] Documentation
• [ ] Maintenance
• [ ] Other (please specify):

---

📚 Documentation preview 📚: https://pymc--7239.org.readthedocs.build/en/7239/

[ricardoV94]

Seems like this is mostly shuffling around and simplifying stuff that already exists, so if tests pass it looks great.

There are two commits in this PR. The first one shuffles and refactors things so that the second commit (converting existing RandomVariables to SymbolicRandomVariables) is done mostly without hassle.

I'm a bit unclear on how the signatures for RVs work, was that changed in this PR or another one? The square brackets in particular throw me off.

I think this is the kind of signature we should use in PyTensor, so I was testing it here. The numpy vectorize signature doesn't really handle stuff like rng, size, axis, so I think we should take the initative here. In a previous PR I pretend those were scalars, so stuff looked like (),(),(),()->(),(), which is both fake and I think less readable than [rng],[size],(),()->[rng],(). Wdyt? This would ultimately replace the ndim_supp and ndims_params which is very strict and only works because we assume all RVs have the same non-numerical signature. This is not useful for SymbolicRandomVariables that can have multiple (or zero) RNGs and only optionally size.

There's also some opportunities for refactoring duplicated code.

I'm weary of some helpers, but I can optimize for a bit less DRY

[ricardoV94]

@jessegrabowski I simplified the logic needed to build standard SymbolicRandomVariables, what do you think?