Remove support for self-contained output during dotnet build

[sbomer]

The discussion around defaults in #30104 led to the suggestion to get rid of self-contained builds. Collecting the main relevant comments here:

@agocke in #30104 (comment)

I don't like self-contained dotnet build at all. I think that should be a publish-only gesture.

@agocke in #30104 (comment):

My preference is that we would change SelfContained to mean PublishSelfContained. If you want a self contained build, you'll need to execute a publish. Basically the same behavior, just behind a different verb.

@richlander in #30104 (comment)

I see. This change would mean that we are for sure saying that the way to produce final prod apps with .NET is via publish. I think we're mostly there anyway. If no one else wants to raise a concern, I'm good with that. In fact, it might simplify the whole model.

@baronfel @dsplaisted

@dsplaisted in #30104 (comment)

This seems like a major change breaking change. Maybe publish should be the way to get the final prod app, but I bet there are lots of people that don't do it that way today.

One thing that springs to mind is Exe to Exe project references. It's somewhat of a niche scenario, but today you can have a self-contained app reference another self-contained app, and you can get a working copy of both in the output folder. This wouldn't work with publish, since when you publish a project, you don't publish its project references.

(There was some further discussion of alternative ways to accomplish the Exe-to-Exe project reference behavior, starting from #30104 (comment))

Related: #32277

[richlander]

I like this, however, we need to reason about this w/rt app types that need self-contained like Wasm and iOS.

I think we're really saying that we want to change this for the traditional CoreCLR scenarios. I'm good with that.