[proto] Fix kernel passthrough and types of Normalize

[datumbox]

Addresses some of the remarks at #6486

Depends on #6487

This PR:

• Ensures Normalize uses the right _transformed_types
• Removes the passthrough functionality from the F.normalize() kernel
• Updates the error message to the one on main branch

[pmeier]

Can we also have Sequence[float] here and convert to list again before calling the kernel? Since we already do this conversion in the transform, there will be no extra conversion when repeatedly calling this from there. On the other hand, users that only want the functional get the benefit of not only using lists.

[datumbox]

I agreed this could be a good change. But it's quite big and should be discussed further because it's changing the signature of a public method. F.normalize() exists already on the old API. Perhaps we can do this because we already change the type of inpt. But I think that's beyond the scope of this PR.

I think whether we can do this or not, depends on whether we will be able to keep F jit-scriptable. Our earlier efforts with @vfdev-5 showed that this might not be possible, but it would be really good if we could keep it as this would be the biggest BC-break of the proposal.

[datumbox]

Let me add a bit more info here to have a bit more context.

If we had a way to detect that a certain Tensor object is a "simple tensor" while JIT-scripting, then we would be able refactor the entire F API to keep it JIT-scriptable and maintain BC. This could require some nasty tricks like:

• Faking types
• Splitting the non-jit scriptable part of F high-level kernels in separate methods that are marked with @torch.jit.unused.
• Extensive use of torch.jit.is_scripting() and torch.jit.is_tracing()

Another thing we could do if we want to avoid BC breakages is to provide a jit-scriptable F that has exactly the same signatures as the high-level kernels but only supports pure tensors.

To keep the above a possibility, we shouldn't modify prematurely the existing signatures to receive parameters that are not JIT-scriptable (like Sequence). We might end up doing it at the end, but let's hold off to that until we know for sure.

[vfdev-5]

lgtm, thanks @datumbox !

[datumbox]

The failing test is unrelated.