Increase precision and safety of the NonVersionableAttribute (#70327)

Increase precision and safety of the NonVersionableAttribute (#70327)

* Increase precision and safety of the NonVersionableAttribute
- NonVersionable now only unconditionally affects whether or not the IL is reported as inlined in the inlining data
- Primitive types are now implicitly considered to be NonVersionable
- Classes defined in CoreLib may now be considered to be NonVersionable
  - Classes now marked are String, RawData, and RawArrayData, which are all tied into intrinsics in crossgen2
- NFloat is now marked as NonVersionable so that some of its methods may actually be treated as NonVersionable
- There is now an additional predicate that the IL within the NonVersionable method must satisfy a series of tests to ensure that it can safely be inlined without adding additional tokens for the logic to depend on. See below for the details of the predicate

Collectively these changes make it so that even if we change our inlining rules, the NonVersionable marked methods will successfully pass through Crossgen, without generating requiring tokens from their original modules to be present in the final image.

The rules are:
                // 1. ldfld, ldflda, and stfld to instance fields of NonVersionable structs and NonVersionable classes
                // 2. cpobj, initobj, ldobj, stobj, ldelem, ldelema or sizeof, to NonVersionable structures, signature variables, pointers, function pointers, byrefs, classes, or arrays
                // 3. stelem, to NonVersionable structures
                // In addition, the method must not have any EH.
                // The method may only have locals which are NonVersionable structures, or classes

* Address code review feedback