Clean up usage of BinaryFormatter throughout codebase

[GrabYourPitchforks]

See https://github.com/dotnet/corefx/issues/38760 for more information.

There is a possibility that the BinaryFormatter type might be moved out of the shared framework in a future release. Since WinForms is part of the shared framework, the code base should begin preparing for this transition. The following steps will help ensure that if a "safe" BinaryFormatter-compatible serializer is introduced in place of the original BinaryFormatter type, WinForms will be able to drop its dependency on the legacy type and move on to the new type with minimal friction.

1. Consider all usages of BinaryFormatter already in the code. Is it absolutely mandatory that each of these usages be present? Is there a critical business or customer scenario that this fulfills that cannot be addressed by some other technology? Consider that some types (like Delegate) which are serializable in Full Framework are not serializable in Core, so this might affect some call sites which were kept for "back compat" reasons but which were not fully tested. If a call site does not need to exist, remove it.

2. Of the remaining usages, ensure that a type-limiting SerializationBinder is always present. Do not allow any code path which might bypass setting the SerializationBinder on the serializer instance. (This guidance only applies to call sites where Deserialize is called.)

If there are any places where these requirements cannot be met then we can work through them on a case-by-case basis. Thanks!

[merriemcgaw]

Let's look through the codebase for all usage of BinaryFormatter. I'm thinking clipboard scenarios (@Tanya-Solyanik others?) We can get back to @GrabYourPitchforks with everything we know.

[weltkante]

Clipboard and drag'n'drop of nontrivial content relies on BinaryFormatter. If you want clipboard/drag'n'drop between older Desktop Framework applications and newer .NET Core 5 applications the replacement needs to be able to produce/consume the same binary data.