Return correct type indices for primitive types referred to by their CLR type names

[aparajit-pratap]

Purpose

Return correct type indices for primitive types referred to by their CLR type names - this permits a node like List.RemoveIfNot to work with not just the DS types passed as input, but also the C# type. For e.g. it now works for both the DS type int but also the equivalent C# type, System.Int64 type.

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• This PR modifies some build requirements and the readme is updated

Release Notes

List.RemoveIfNot now supports C# type such as that returned from Object.Type.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

[mjkkirschner]

while I think this PR looks good - I am curious if you think there could be performance implications here, this IndexOf call doesn't seem to be straight forward, it seems to do partial matching? So in the worst case we'll now do 2x the lookups in some pathologically bad cases, do you think those will come up rarely, and if so is this method classTable.IndexOf linear in complexity or something worse?

[aparajit-pratap]

I think right now, it's only going to take place for a node like RemoveIfNot where there is the possibility of checking for a C# type.

[mjkkirschner]

LGTM