Validation: local noinline functions in library treated as export functions

[tex3d]

DxilValidation will treat [noinline] functions as if they are exported functions, even though they are local, and rules should be different (depending on what calls them).

Currently, operations that are legal in specific shader stages, but not export functions, are allowed in [noinline] local functions called by the main entry function when compiling to a non-library target. However, these same operations will fail validation when compiling the same code to a library, due to the treatment of [noinline] functions as if they are export functions.

One way to resolve this discrepancy is to tighten the validation for [noinline] functions for non-library shader targets, by considering them to be like export functions in this context as well. This will start failing code that is currently considered legal. However, [noinline] usage should be rare, and is already considered somewhat experimental and use at your own risk due to known bugs here.

If we wanted to fix this for libraries, we could do so by constructing a mask of the types of entry (or export) functions that call each internal function, then use that mask to check legal intrinsic usage. This same mask approach is already used to construct export function compatibility masks in the RDAT part.

This shader succeeds if compiled to ps_6_8, but fails if you compile to lib_6_8 due to this issue:
https://godbolt.org/z/eWYcrn48W