[PoC] move metadata computation from prototype features into kernels

[pmeier]

As discussed offline. Moving the computation to the kernels has several upsides:

1. We would have the computation in one place rather than scattered on the kernel as well as on the feature. In some cases that might also be a performance improvement since we don't need to recompute intermediate values.
2. Users that want to use the prototype kernels directly currently don't have access to the metadata we compute and thus have to do it themselves. This somewhat defeats the idea of providing kernels for all the transforms since we only provide part of the computation.

The only downside that I see is that now some kernels don't have a more complex output. Since there is no hard rule that the kernels need to return a single tensor, this should not effect anything but our test suite. The test suite currently at some places depends on a single tensor return, but this is trivial to change. I have not touched the tests yet, so they are currently failing.

@vfdev-5 also suggested that the kernels could have a return_metadata: bool = False flag. Using this, the users by default will always only get a tensor back, while they have the option to get the metadata as well. I'm usually against changing the return type through an input flag, but the consistent return type for all kernels is also appealing. However, if we want to go for that, we need to check if JIT is happy as well. The annotation, e.g. Union[torch.Tensor, Tuple[torch.Tensor, Tuple[int, int]]] for the bounding box kernels from this PR, should not be an issue, but I'm not sure if JIT can work with the output, i.e.

output1 = kernel(...)
output2, metadata = kernel(..., return_metadata=True)

If it can't, I'm strongly against this variant, because we then need more workarounds or the like that make the API more complex than a few kernels that return more than just a tensor.

[datumbox]

Overall I'm in favour of this approach. I think the return_metadata=True idea might bring some further speed gains but I don't believe it's JIT compatible (we do a conditional return on Object Detection models an it's exceptionally hacky to make it JIT-scriptable).

I think before merging this, we need to fix all the JIT-scriptability related PRs we have to ensure nothing breaks it.

@pmeier Are these the only kernels that need to return meta-data or it's just an example and there are more to be changed?

[pmeier]

Are these the only kernels that need to return meta-data or it's just an example and there are more to be changed?

No, these are all kernels that need to be changed.

[datumbox]

LGTM, with a few minor comments.

@vfdev-5 could you please also have a look?