Fix issue with proxied delegates

[manodasanW]

• Delegates do not implement any interfaces, but there are still a couple of vtable entries created for them like IUnknown and the interface which internally represents the invoke function. Typically, all the vtable entries like in C++/WinRT are all pointing to the same vtable, specifically the one with invoke, due to the first point. But when they are proxied, this cannot be assumed given marshaling will check for the size of the IUnknown interface and only marshal that size. This means any extra entries in the vtable may not be marshaled and due to that we will fail to create an RCW. In addition, this also means managed delegates can be marshaled and we implement a couple other interfaces like IInspectable for boxing delegates.
• Address the issue by moving the ordering of the check for delegate as we cannot assume they won't have an IInspectable vtable entry and by adding a QI for the internal delegate interface when we are doing the CreateRcw callback. This will address any existing projections that make the above assumption as it is a change in WinRT.Runtime.
• Also did a similar change in the projections by calling a new version of GetObjectReferenceForInterface which does a QI. This change was made in addition to the other because in non-agile delegate scenarios we need to know the IID of the internal delegate interface in the case we need to get an agile reference for it. Given proxied delegates are a scenario that can occur, we should make sure that this will not fail due to not being able to determine the IID of the common delegate invoke interface we use across all delegates to represent it.
• Added an out of process exe test to validate this based on an existing sample.
• Minor moving around code during vtable construction to reduce the # of checks in the delegate case as we know they don't have interfaces and other minor perf changes.

Fixes #1124