Clean up shader library and introduce some new conventions (#3024)

Summary:
Pull Request resolved: https://github.com/pytorch/executorch/pull/3024

## Context

This changeset introduces some fairly mechnical improvements to the Vulkan compute graph shader library in order to introduce some new conventions.

**Note that backwards compatibility with existing shader authoring methods is preserved**.

### Only List `VALUE` in the `.yaml` files

Previously, to generate variants for a combination of vales, the YAML file will contain

```
    PACKING:
      - VALUE: CHANNELS_PACKED
        SUFFIX: C_packed
      - VALUE: WIDTH_PACKED
        SUFFIX: W_packed
      - VALUE: HEIGHT_PACKED
        SUFFIX: H_packed
```

however, the shader code generation script will use the `VALUE` as the `SUFFIX` if no `SUFFIX` is provided.

Therefore, only the below is needed:

```
    PACKING:
      - VALUE: C_packed
      - VALUE: W_packed
      - VALUE: H_packed
```

### Change indexing utility macros to lowercase

Indexing utility macros have been changed to lowercase, and the packing identifiers have been changed due to the change in YAML files.

The change to lowercase is to make calls to the macro read more like functions (and indeed they are typically used as functions) in order to help make the code more readable.

```
POS_TO_COORD_${PACKING} -> pos_to_coord_${PACKING}
```

### Use convention of defining macros in order to reduce Python code blocks usage

Previously python code blocks were used in the GLSL code itself in order to vary the shader between different settings. However, usage of Python code blocks negatively impact code readability. Therefore, this diff seeks to introduce a convention of defining macros near the top of the shader to reduce the usage of Python code blocks, i.e.

```
#define pos_to_coord pos_to_coord_${PACKING}
#define get_packed_dim get_packed_dim_${PACKING}
#define get_packed_stride get_packed_stride_${PACKING}
```

### Improve GLSL type definitions

Previously, the following Python code blocks were used to determine appropriate vectorized and scalar types:

```
${VEC4_T[DTYPE}} texel = ...
${T[DTYPE]} scalar = ...
```

This changeset replaces that with:

```

#define BUF_T ${buffer_scalar_type(DTYPE)}
#define VEC4_T ${texel_type(DTYPE)}
#define SCALAR_T ${texel_component_type(DTYPE)}

layout(set = 0, binding = 1) buffer  PRECISION restrict readonly Buffer {
  BUF_T data[];
}

buffer_in;
VEC4_T texel = ...
SCALAR_T scalar = ...
```

The main differences are as such:

* `buffer_scalar_type()` produces the same result as `T[DTYPE]`
* `texel_type()` is not determined from a mapping with `DTYPE`, but is determined indirectly based on the image format that is associated with the `DTYPE`.
* `texel_component_type()` is based on the result of `texel_type(DTYPE)`

Essentially, the mapping is more in-line with what happens in code.

The reason for this change is to enable FP16 support and is a bit complicated. Basically, we need a way to distinguish the scalar type used for buffer storage, vs the scalar type used to store a component of a vec4 type (hence `BUF_T` vs `SCALAR_T`). The reason this is required is that to support half-precision tensors, the buffer representation will use a 16-bit float type but textures will still extract to `vec4` (i.e. 4x34bit floats).
ghstack-source-id: 222551445

Reviewed By: jorgep31415

Differential Revision: D56082461

fbshipit-source-id: 49fb8ff5fb0d8c48d0fadd8fd24184cc20db2147