TreeNodeFilterCommandLineOptionsProvider seems to be using the wrong Version

[Youssef1313]

testfx/src/Platform/Microsoft.Testing.Platform/CommandLine/TreeNodeFilterCommandLineOptionsProvider.cs

Lines 15 to 25 in 881b5e6

	/// <inheritdoc />
	public string Uid { get; } = extension.Uid;
	/// <inheritdoc />
	public string Version { get; } = AppVersion.DefaultSemVer;
	/// <inheritdoc />
	public string DisplayName { get; } = extension.DisplayName;
	/// <inheritdoc />
	public string Description { get; } = extension.Description;

To me that's using the platform version but it should use the version of whatever extension being passed.

[Evangelink]

I am actually wondering if we should keep the platform version as we own the implementation. This means we would need to fix what we have done for the bridge extensions.

[MarcoRossignoli]

We own all the logic so I think that we should keep our version, in case of issues we need to know our version not the user version.

[Youssef1313]

In that case, Uid and Description should be ours as well. Currently it's a mix.

And also if we are ending up not needing extension to be given by MTP users, then this parameter will be unused:

testfx/src/Platform/Microsoft.Testing.Platform/Helpers/TestApplicationBuilderExtensions.cs

Lines 14 to 15 in f492095

	public static void AddTreeNodeFilterService(this ITestApplicationBuilder testApplicationBuilder, IExtension extension)
	=> testApplicationBuilder.CommandLine.AddProvider(() => new TreeNodeFilterCommandLineOptionsProvider(extension));

Then we may need to take the break in a next minor release (given it's marked experimental already), and remove the unneeded parameter

[MarcoRossignoli]

It's fine to me keep our naming everywhere, are good for troubleshooting.

[Evangelink]

We are grouping command lines by extensions under info. I am wondering if we should declare them as platform or keep them under the extension so they are still part of the framework.