Editor: reimplement copy/pasting objects via clipboard using AGS own serialization

[ivan-mogilko]

I have not worked with .NET clipboard much, but recently did a group GUI Control copy (6b59e31), and also had to fix a problem related to custom properties in ags4 (274359c).

That's how I found out that in order to support standard clipboard usage, you have to add [ISerializable] attribute to the types you copy, add [NonSerialized] attribute to member fields that you do not want get copied, and generally ensure that all necessary fields can be serialized (not certain what this entails though).
More info on this may be found here:
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.iserializable?view=net-8.0
https://learn.microsoft.com/en-us/previous-versions/dotnet/fundamentals/serialization/serialization-guidelines?view=net-8.0

From what I understood, when doing clipboard copy, .NET likely does not store the objects in memory directly (as i supposed initially), but converts them into certain format.
The point is, that since we already have our own generic serialization mechanism in the Editor, having another mechanism seems superfluous. While ours works with properties, ISerializable works with fields. This makes them be also not fully consistent, as each copied type will have to, for instance, care about marking both which properties to not serialize in AGS project files, but also mark which fields to not serialize when making a copy for clipboard. This is extra hassle, extra code, and may be prone to oversights.

For that reason, I propose to remake existing copy/paste operations using our internal serialization, where makes sense (i.e. unless we copy an image, or something of that kind). I think this may be done by serializing our type into the string using existing ToXml methods, passing that string into clipboard, and then deserializing it back using FromXml. This way we guarantee that any object in game that may be saved on disk may be also copied through the clipboard in exact same way.

See Also: #601 - this may use similar mechanism