Handle possibility of bad types in varying input/output signature.

[tangent-vector]

Fixes #160

If the front-end runs into a type it doesn't understand in the parameter list of an entry point, it will create an ErrorType for that parameter, but then the parameter binding/layout rules will fail to create a TypeLayout for the prameter (and return NULL).
There were some places where the code was expecting that operation to succeed unconditionally, and so would crash when there was a bad type.

The specific case in the bug report was when the return type of a shader entry point was bad:

// `vec4` is not an HLSL type
vec4 main(...) { ... }

Note that the specific case in the buf report only manifests in "rewriter" mode (when the Slang compiler isn't allowed to issue error messages from the front-end), but the same basic thing would happen if the varying parameter/output had used a type that is invalid for varying input/output:

Texture2D main(...) { ... }

I'm not 100% happy with just adding more NULL checks for this, because there is no easy way to tell if they are exhaustive.
A better solution in the longer term might be to construct a kind of ErrorTypeLayout to represent cases where we wanted a type layout, but none could be constructed.

[nbentyNV]

Are you preparing a new package for me? It will go into the dev branch, I'm not concerned about new features.