Tracking odds and ends for the pytorch backend with pymc

Description

Some of the bigger issues I came across when doing an integration pass with pymc and pytensor were

1. (Trivial) allow pytorch in the config defaults
2. Some of the Op implementations (e.g. Elemwise) don't always return a tensor, which although expected when you have multiple outputs, caused some upstream failures when creating initial points.
3. The linker would return torch tensors always, but when pymc would attempt to copy any of the results or create a buffer for whatever reason sharing a dtype, we would fail (numpy doesn't know what to do with torch.float)
4. Lots of graph breaks due to pytorch not liking how we do code generation (that is why the code is littered with torch.compiler.disable).

I'll post a more detailed torch analysis in a comment for 4.

Start by separating the four areas listed in the description: config defaults, Op implementations such as Elemwise, linker tensor and dtype handling, and PyTorch code generation. Use the PyMC/PyTensor integration pass as the validation point; done means the listed initial-point, copying, buffer, and graph-break failures no longer occur.