Add support for building tool packages with runtime identifier set without building RID-specific packages

[dsplaisted]

Fixes #51199

Description

Allows customers whose projects are affected by our tools breaking changes to set a property to restore the previous behavior.

Now that we support RID-specific tool packages, setting a RuntimeIdentifier for a project with PackAsTool set to true will create a RID-specific tool package without a primary package. With this PR, you will be able to restore the previous behavior by setting the following properties:

    <CreateRidSpecificToolPackages>false</CreateRidSpecificToolPackages>
    <UseAppHost>false</UseAppHost>

Customer impact

Allows customers who were building .NET tool projects with a RuntimeIdentifier specified to opt in to the same tool package creation behavior as the .NET 9 SDK. We don't expect that this is a very common scenario, but for those impacted there is not a good workaround without this change.

Regression

Yes, we made intentional breaking changes from .NET 9.

Testing

Added automated test to cover this case and did additional manual testing

Risk

Low

[baronfel]

LGTM as is, but I have a discussion going on in Teams about if we can use CreateRidSpecificToolPackages in more places to remove the need to also set UseAppHost.

[baronfel]

Daniel and I chatted more and we don't think my idea would work/be that much more usable. So this is good. When we get Tactics approval we'll need to go update the breaking change notice for RID specific Tools.

[baronfel]

Approved over mail, so merging for GA. Created dotnet/docs#49289 to track updating the breaking change notice.