Consider aggressive AppContext switch for enabling safer BinaryFormatedObject usage

[JeremyKuhne]

All BinaryFormatter blocks should be behind an AppContext switch. For now this will be an opt-out, when and if the BinaryFormatter gets disabled by the runtime this can be driven by whatever is driving the behavior in the runtime.

Now that we have BinaryFormattedObject, thinking of this in terms of aggressive opt-in of it where we don't support full fidelity. For example, we don't support custom comparers for HashTable.

[JeremyKuhne]

As part of this we should bring back #7986 under this switch.

[JeremyKuhne]

I'm presuming that this switch should be something like "WindowsFormsDoNotUseBinaryFormatter" and it should be opt-in. The idea here is that you can say "I don't want my app to try to use the BinaryFormatter, enabled or not". The questions:

1. Do we want have discreet switches for each type of usage? An overall switch? Both?
2. Does this even matter in the individual cases? If the specific case would fail in the same way with/without the switch it might be moot.

We'll list each of the cases here before we fully design the solution.

[merriemcgaw]

@JeremyKuhne @lonitra do we still need this? Is there anything we need to in our templates for .NET 8

[JeremyKuhne]

Thinking has changed on this one. The idea now is to potentially add a switch that forces usage of our "safer" binary formatting code when possible. This still needs quite a bit of thought, and we might not do anything. Moved to 9.0.

[JeremyKuhne]

I don't think there is anything to do here.