Tensor construction warnings

[alvorithm]

This PR adds a little helper function to prevent tensor construction warnings when passing a torch.Tensor-typed argument to torch.tensor().

[alvorithm]

Re. AffineTransform replacing AffineScalarTransform the test fails on the logabsdet of the inverse in standard_test.py::AffineScalarTransformTest. I could have a look tomorrow, if you don't immediately see the reason.

[alvorithm]

Ok, the commits above implement all the changes we've discussed so far

• typing
• unifying AffineScalarTransform and AffineTransform under PointwiseAffineTransform.
• more explicit (IMHO) treatment of defaults, but compatibility classes still allow passing None (e.g. the tests use the old interface).
• some more goodies.

Note I had to special-case scalar scale to match the expectation of the tests to within eps=1E-6. Using the .sum() idiom leads to disagreements ~1E-5, and is perhaps slower. But now the special casing is confined to a little function, where it can be suitably documented. Also, this function could be memoized if the transform is applied multiple times (or even in fwd and inv modes) with the same batch_shape.

[alvorithm]

Thanks, Artur, and please keep the nitpicks coming, I love them!

In this installment

• I implemented your suggestions (but see comments)
• I switched to using .size() instead of .shape, since a) we are demanding inputs to be tensors and b) in preparation for named tensors, which will be supported by .size(), but I reckon not by .shape.
• It's a bit sad that torch did not follow numpy terminology here, because as a consequence this reads slightly confusing:

  batch_size, *batch_shape = inputs.size()

• what do you think instead of

  batch_len, *batch_size = inputs.size()

• for readability I encapsulated the prod dance in a numel function in torchutils that works with Tensors or Tensor Sizes.
• Recovered docstring that I had let slip inadvertently. We could add some more text there. In general, what do you think of systematically adopting the notation in the recent review by George et al.? That would have us use Z instead of X. We could give that paper in the README.md as entry point to understand the package.
• in torchutils I reimplemented notinfnotnan using torch.isfinite. Since the idiom is so short and self-explaining, and there are no uses in the code that I could find, I actually would suggest to remove the function.

[alvorithm]

• Dispensing with ensure_tensor since torch.as_tensor does what we want.
• Ditto for numel. Caveat: <my_tensor>.numel() and <my_size>.numel() do each the right thing, but you have to ensure then that you have a size.
• Added return types for methods
• More unspecific return type of notinfnotnan, as Tensor (I learnt) cannot be subscripted. We could solve this defining own types, but postponing this since notinfnotnan does not seem necessary anymore.