_WalkEachTargetPerFramework (Pack) should list inner builds the same way as during the build step

[xen2]

Issue
_WalkEachTargetPerFramework (used to list files for each TFM during Pack) is currently enumerating builds to pack with only the hardcoded case of TargetFrameworks in mind (Projects="$(MSBuildProjectFullPath)" and TargetFramework=%(_TargetFrameworks.Identity)).
This makes it quite difficult to extend, and is separate from the build dispatch (done by _ComputeTargetFrameworkItems).

Example use case

• MSBuild.Sdk.Extras for building one library per RID
• Stride Game Engine (my project) for building one library per graphics API

Proposal:
Unify the build dispatch and packing by reusing the same list, @(_InnerBuildProjects) instead.
It is computed during Build in _ComputeTargetFrameworkItems.

On top of keeping build and pack in sync, it allows for much easier extensibility (current workaround is to do a full copy & paste of _WalkEachTargetPerFramework and all its sub targets).

Excerpt of _WalkEachTargetPerFramework before the change:

<MSBuild
      Condition="'$(IncludeBuildOutput)' == 'true'"
      Projects="$(MSBuildProjectFullPath)"
      Targets="_GetBuildOutputFilesWithTfm"
      Properties="TargetFramework=%(_TargetFrameworks.Identity);">

After:

<MSBuild
      Condition="'$(IncludeBuildOutput)' == 'true'"
      Projects="@(_InnerBuildProjects)"
      Targets="_GetBuildOutputFilesWithTfm">

(_InnerBuildProjects already contains the AdditionalProperties with TargetFramework properly set. The cool thing is that we can easily add custom ones such as RuntimeIdentifier=win-x64, this will affect both Build and Pack)

Do you think of any case where this wouldn't work?
If everybody agrees, I am happy to submit a PR for that.

Note: this is just the first step. About the use case described earlier (multiple DLL per RID or graphics API rather than only by TFM), there's still a bunch of other tedious changes & target overrides to do.
I plan to submit other PRs later to improve on that (if they are welcome, I am not sure it's a priority).

[nkolev92]

Related to #5154.

I think the linked issue captures the general scenario of building for a target framework more than once.
At this point we'd prefer not to take a dependency on _InnerBuildProjects (it's _ for a reason, internal and not suggested to be used outside of the defining targets), and rather listen for more feedback first.