Fixed bugs in ManagedMethod parsing, and updated hierarchies.

[Haplois]

Our FQN API is finalized, this PR makes it compliant with Visual Studio.

• Hierarchy order reversed to make it easily expandable. Currently, we only support 4 levels.
• Hierarchy API revised to return all 4 levels which are: Test group, class name, namespace, and container.
• Test group by default is managed method name without adapters.
• Fixes Exception: Sequence contains more than one element #2926

Hierarchies are for display purposes; we need to change how we generate those:

• Switch to using closed types instead of open. TestMethod<string> instead of TestMethod`1.
• Append method parameters to Test group if any, do not append () if not.
• Namespace can be string.Empty in case of no namespace. Make sure that works as expected, and we're able to resolve when provided.

Breaking changes

• Hierarchy generation changed, RFC to be updated to reflect this. (Add RFC spec for Hierarchy property vstest-docs#261)
• Although this breaks compatibility with older versions of Hierarchy since those versions were officially released and never used by anyone - support will start with the first version we release. It will be bound to TP version, and adapter version. Check is done inside Test Explorer.

[nohwnd]

Can you add more info to the PR description please?

[nohwnd]

My main concern is about breaking backwards compatibility. What is the consequences of that?

[nohwnd]

So how does this work when adapter utilities on testhost side and on IDE side are different? How do we keep compatibility with MSTest that is currently using this, like 2.2.9?

[Haplois]

We'll handle those on the test window side. No one except us uses this, so in older versions we just fallback to old approach for display purposes.

[nohwnd]

Based on what will you handle it? The array size or the actual version of the mstest?

[Haplois]

Yes, we will only enable this on next release. (That part is not baked in TE yet.) Also if an adapter returns something not supported we will fallback to current behavior.

[Evangelink]

One last comment.

PS: It'd be better to have a separate PR for the assemblyinfo changes as they do not relate to this change.

[nohwnd]

Approving, because I am promised we can iterate on the design. And hopefully make the values separate properties that will be output only when they have non-default values. And same for the FQN properties, because keeping them custom (in property bag) adds a lot of overhead.