The catch with these operations is that they return a vector based on the scalar of the element type of the texture.
That is, given `Texture2D<float> t` the operation `t.GatherRed(...)` should return a `float4`.

The ideal way to solve this would use associated types, but we aren't there yet, so I am using extension declarations.
An extension can "capture" the identity of the element type, like so:

    __generic<T, let N : int> __extension Texture2D<vector<T,N> > { ... }

That extension will match `Texture2D<float3>` and correctly capture `T == float`, so that we can use it in other operations.

Getting this working required a bunch of changes:

- Actually emit the relevant extension declarations in the stdlib

- Fix the parser to be able to parse `Texture2D<vector<T,N> >` (that is, a nested generic app).
  - I actually went ahead and significantly overhauled the expression parser while I was there, because I just couldn't deal with the existing code any longer.

- Added support for general-case lookup to look through `__extension` declarations. I had logic in place to special-case this for looking up "constructors" but hadn't done anything for general member lookup yet.
  - This required some annoying holes to be punched through the layers, because lookup might need to invoke semantic analysis to ensure that an extension has been checked.

- There is some first-pass code trying to support looking up a `typedef` nested inside the `vector` type. This is a nice idea in principle, but the problem is that the `Texture2D<T>` definition would be looking up `T.Element` and not `float4.Element`, and that means we'd need machinery for doing lookup *through* interface conformances for a type parameter like `T`

The big gotcha here is that none of this logic applies to `Texture2D<float>` (the original case I mentioned) because I am matching vector types and not scalars.
Matching scalars *should* be as easy as:

    __generic<T : __BuitlinScalarType> __extension Texture2D<T> { ... }

But I'd need to confirm that interface constraints like that actually work, or else that extension would *also* apply to `Texture2D<float4>` and break everything.