Revamp prototype features and transforms

[pmeier]

This PR is a large overhaul of what we currently have for prototype features and transforms. For larger changes, individual PRs were send to this branch.

[facebook-github-bot]

💊 CI failures summary and remediations

As of commit cc16b56 (more details on the Dr. CI page):

---

• 1/1 failures introduced in this PR

---

1 failure not recognized by patterns:

Job	Step	Action
cmake_macos_cpu	curl -o conda.sh https://repo.anaconda.com/miniconda/Miniconda3-latest-MacOSX-x86_64.sh
sh conda.sh -b
source $HOME/miniconda3/bin/activate
conda install -yq conda-build cmake
packaging/build_cmake.sh
	🔁 rerun

---

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[datumbox]

All changes up until f795349 commit are from PRs that were already reviewed. Any commit after needs to be reviewed.

[datumbox]

LGTM, let's merge when CI is green.

[datumbox]

This PR reimplements the New Transforms API and is the result of offline discussions with @pmeier and @vfdev-5. It's not the final adopted solution but the latest candidate. More ideas will be discussed soon.

Here I summarize the main point of this solution:

• There are 2 types of kernels. The high-level ones (such as resize()) which can handle all types of input and the low-level ones (such as resize_image()) which handle specific types.
• High-level kernels are located here. They receive inputs of various types (such Image, BoundingBox etc) and are responsible for dispatching to the correct low-level kernel by using the rich meta-data available on the custom types. Usually they are a thin layer that mostly maps types to operations but sometimes additional massaging is required prior calling the low-level kernel. High-level kernels are not JIT-scriptable.
• Low-level kernels are located here. They are specialized for each type of input and operate on raw PyTorch Tensors (or PIL Images) and thus they require passing to them all the necessary meta-data required to perform the calculations. The low-level kernels are JIT-scriptable and can be used by downstream libraries without requiring using the proposed Feature types of TorchVision.
• The dispatching is currently performed a simple annotation mechanism. This targets to remove most of the boilerplate code for 90% of simple cases that just map an input to a kernel. Thus in most cases, the main body of the high-level kernel is omitted. Nevertheless, there are some cases where extra massaging is needed for specific types. When this is needed, we pass None to the mapping and the actual handling of the dispatch happens on the body of the kernel.
• It's worth noting that kernels of the same operation (such as resize) might require different input parameters for different types (example 1 vs 2). Thus currently, the dispatcher just receives args/kwargs and forwards them to the low-level kernels. Occasionally we enhance these parameters with available meta-data to avoid explicitly requiring them (TBD if overwriting meta-data will be allowed). In the documentation, we link to the low-level kernels to show which parameters are needed for the operation.