Update base for Update on "[ET-VK] Clean up prepack API"

## Context

As title, revamp the prepacking API:

* Make the naming more clear; i.e. `prepack_if_tensor_ref` to `prepack_standard` to disambiguate the packing logic that will used.
* Instead of passing through the `v` argument if it is a `Tensor` by default, this functionality must be toggled via the `passthrough` argument. The goal is to  encourage developers to be more explicit about what types they expect the operator arguments to be.
* Consolidate API surface and reduce the number of overloads

Past the API changes, I have also removed a bunch of unnecessary calls to `prepack_if_tensor_ref` throughout the operator implementations. The most common cases were calling it on an input tensor which is not necessary.

## The "big picture" for prepacking

`TensorRef` objects and prepacking are used whenever we are dealing with a Tensor whose data is serialized with the model. However, these "serialized tensors" all belong to one of two categories

* Weight/biases: trained weights and biases that act as the state for a i.e. Convolutional or Linear layer. These tensors are used only within the `nn.Module` that they belong to
* Persistent tensors: tensors whose data just happen to be invariant to the inputs, and their data can be serialized with the model itself. They are treated as regular tensors and may be used in several operators throughout the model. One example is `freqs_sin` and `freqs_cos` in Llama models which are used to calculate rotary positional encodings

For weights and biases, the way that the serialized data should be packed may be dependent on the operator it is used in. However, for persistent tensors they must be packed with the "standard" staging to tensor algorithm since they are the same as regular tensors.

While it is well known which operators expect weight tensors. However, persistent tensors are tricky because they can be used as an argument to any operator. This would mean that every operator needs to account for the possibility that one of their inputs will be a serialized tensor. This is undesirable because it adds an additional layer of indirection when processing operator inputs on top of the fact that every argument is actually a reference to a`Value` object in the graph, which itself is a wrapper. It also makes things complicated for the operator developer. Another downside is that persistent tensors will be packed multiple times, once by each operator that uses it.

To address this, I plan to handle persistent tensors at export time by inserting a `prepack()` operator for them which will cause operators that use the serialized tensor to see a Tensor object instead of a TensorRef object. This will make it so that the only operators that should expect to prepack an argument are tensors that expect a weight argument, and also avoid packing persistent tensors multiple times.

Differential Revision: [D64550560](https://our.internmc.facebook.com/intern/diff/D64550560/)

[ghstack-poisoned]

Author: SS-JIA

examples/portable/custom_ops/custom_ops_1_out.cpp

@@ -20,11 +20,11 @@ void check_preconditions(const Tensor& in, Tensor& out) {
   ET_CHECK_MSG(
       out.scalar_type() == ScalarType::Float,
       "Expected out tensor to have dtype Float, but got %hhd instead",
-      out.scalar_type());
+      static_cast<int8_t>(out.scalar_type()));
   ET_CHECK_MSG(
       in.scalar_type() == ScalarType::Float,
       "Expected in tensor to have dtype Float, but got %hhd instead",
-      in.scalar_type());
+      static_cast<int8_t>(in.scalar_type()));
   ET_CHECK_MSG(
       out.dim() == in.dim(),
       "Number of dims of out tensor is not compatible with inputs");

kernels/test/custom_kernel_example/op_relu.cpp

@@ -87,7 +87,7 @@ my_relu_out(KernelRuntimeContext& context, const Tensor& input, Tensor& out) {
           InvalidArgument,
           out,
           "Unhandled dtype %hhd",
-          input.scalar_type());
+          static_cast<int8_t>(input.scalar_type()));
   }
 #undef RELU