These were already being handled a little bit, by lowering an `out T` or `inout T` function parameter in the AST to a function parameter with type `T*` in the IR, and then emiting explicit loads/stores.
The HLSL emit logic, however, couldn't tell the difference between an `out` parameter, an `inout`, or a true pointer (if we ever needed to support them...).

The intention (not fully implemented) was that we'd use a hierarchy of types rooted at `PtrTypeBase`:

- `PtrTypeBase`
  - `Ptr`: "real" pointers in the C/C++ sense
  - `OutTypeBase`: pointers used to represent by-reference parameter passing
    - `OutType`: IR level type for an `out` parameter
    - `InOutType`: IR level type for an `inout` or `in out` parameter

Actually implementing this involved:

- Adding a bit more flexibility to the `Session::getPtrType` logic to allow for creating any of the concrete types above

- Making the `lower-to-ir` logic create the right type for function parameters (instead of just using `PtrType`)

- Making the HLSL emit logic check for the `OutType` and `InOutType` cases rather than just `PtrType`

- Changing a bunch of small places in the code so that they use `PtrTypeBase` instead of `PtrType` when they should handle any of the above cases, and also make a few places check for `OutTypeBase` instead of `PtrType` or `PtrTypeBase`, when they are really trying to capture by-reference parameters

- Add a test case that uses all of the different cases we care about (without these fixes, this test case generates errors from fxc because of variables being used before being initialized, becaues parameters get declared `out` that should be `inout`).

A minor point here is that we are playing a bit fast and loose right now because the IR does not actually enforce any type checks. From the standpoint of the front end, `Ptr<T>`, `Out<T>`, and `InOut<T>` are all unrelated types (each is just a `struct` declared in `core.meta.slang`), but this doesn't really matter because none of these are types our current users are explicitly using.

In the IR it makes perfect sense to allow `Out<T>` or `InOut<T>` as the operand of a `load` or `store` instruction (and ditto for `getFieldAddr`, etc.) - there instructions just apply to any `PtrTypeBase`. The place where this potentially gets tricky is whether an `Out<T>` can be used where a `Ptr<T>` is expected, or vice vers (e.g., can I just pass my local variable's pointer directly to an `Out<T>` function parameter?

I'm going to ignore these issues for now, since the code currently works for our test case.