Don't use BinaryFormatter for ClientInfo

[StephenCWills]

Replaces BinaryFormatter with custom serialization methods that utilize BigEndian and UTF-8. I chose not to implement ISupportBinaryImage because this class has a lot of immutable properties that need to be assigned in the constructor.

[ritchiecarroll]

This looks fine. Presume you've have tested? Was trying to think of how this might break -- the only way that occurred to me was the rare case of using an old version console or manager with a new version of server (or vice/versa), like from different machines. I've done this before, but I don't recall any normal cases of us doing this in the field.

[StephenCWills]

Yes, I've indeed tested this.

As for how it could break, I decided that since this is a network protocol that is rarely used over any interface besides localhost, there should be very little risk in breaking the wire format. If we do need to keep things backwards compatible, then the fix will obviously be more complicated. To parse BinaryFormatter payloads, we can use Microsoft's recommendation, but I'd really rather treat backwards compatibility as a last resort.

https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-migration-guide/read-nrbf-payloads