Metal: Slang does not legalize `[[color(n)]]`/`[[attribute(n)]]` attributes correctly

[ArielG-NV]

Metal: Slang does not legalize `[[color(n)]]`/`[[attribute(n)]]` attributes correctly

[ArielG-NV]

note: this is very similar to hoistEntryPointParameterFromStruct

[jkwak-work]

Is this duplicate to #4375 ?

[ArielG-NV]

Is this duplicate to #4375 ?

Looks like it is a partial duplicate.

[[color(n)]] is fragment shader, not vertex shader. I noticed the issue does discuss fragment shader inputs though.

[ArielG-NV]

Plan to fix the following issues (all steps are independent and should compile/work, may split into multiple PR's):
[PR to fix this code-gen problem]

1. Allow n number "allowed types" instead of only two "allowed types" for when legalizing System Semantics for Metal - done
2. Add logic to legalize Structs for attributes. We do not need to flatten the struct, but we do need to annotate each member appropriately (and account for attributes of nested structs shared across entry points) - done
3. Use [2] to add logic to legalize output attributes - done
4. Use [2] to add logic to legalize input attributes - done
5. Make more explicit tests for this section of code to make problem diagnosis easier in the future - done
   note: moved some EntryPointVaryingParamLegalizeContext logic to legalizeEntryPointForMetal since some effort was already done for this and cleanup can be done later-on

Reasons for clean up PR to be seperate
6. Move parts of legalizeEntryPointForMetal into EntryPointVaryingParamLegalizeContext so code compiles
7. Restructure so User Input Semantics legalization works
8. Restructure so User Output Semantics legalization works.
9. Restructure so System Semantic legalization works