Remove hardcoding of TFMs in wasm tests

[ericstj]

One case was discussed here #123100 (comment)

This could be removed by ensuring that props in the SDK define the path of the tasks, and those props get imported by the test-generated project. This TFM in the path to the folder containing tasks is completely unnecessary coupling to the framework version. The product itself only ever cares about two frameworks and only selects between those two.

runtime/src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in

Lines 4 to 5 in f7c4c8c

	<_TasksDir Condition="'$(MSBuildRuntimeType)' == 'Core'">$(MSBuildThisFileDirectory)..\tasks\${NetCoreAppToolCurrent}\</_TasksDir>
	<_TasksDir Condition="'$(MSBuildRuntimeType)' != 'Core'">$(MSBuildThisFileDirectory)..\tasks\${NetFrameworkToolCurrent}\</_TasksDir>

There is probably more hardcoding that can be removed. If necessary we could have a source-generator flow MSBuild properties into the test sources, but ideally we can just make the tests do things that users would (or closer to what users would) and not need to "know" too much about the shape of the product's internal paths.

[ericstj]

Having a look at the use of GetFilesToPackage in all the task projects - https://github.com/search?q=repo%3Adotnet%2Fruntime%20GetFilesToPackage%20path%3A%2Fsrc%2Ftasks%2F**&type=code they choose to include framework version in the path, but this can all be removed for a version-less path.

The targets mentioned above are responsible for selecting which is used. Those can have version removed.

The tasks which hardcode these versions can either remove the versions (as others) or leverage the targets.

[ericstj]

This was also a problem in the product targets - dotnet/dotnet#4205 is where we missed updating a TFM. We should remove the versions from the paths, and also have the runtime tests import the built props so that they can test we get it right.