Reconsider use of SerializableAttribute

[airbreather]

[Serializable] on its own is easy, but it has problems: versioning, lack of control, and fields are opt-out.

If we're going to keep supporting serialization / deserialization for instances of our types, then I recommend that we at least implement ISerializable (with (SerializationInfo info, StreamingContext context) constructor) wherever we do.

Though, if you ask me, I think [Serializable] is probably not that helpful in our context to begin with. There are plenty of platform-independent binary / text formats that support copying geometry instances from one place to another. .NET-specific serialization / deserialization on top of that doesn't seem to justify itself.

So one thing we could do instead of ISerializable would be to just remove the [Serializable] tags for v2, see if that actually breaks anybody's workflow, and then consider how best to resolve that, in the context of all the serialization options available now that we're not limited by the APIs supported on v1 platforms.

[FObermaier]

I don't know if anyone relies on [Serializable], but removing it here implies we remove it / change it in NetTopologySuite as well.

Nobody has yet yelled that the way it is implemented now imposes any problems.

[airbreather]

removing it here implies we remove it / change it in NetTopologySuite as well.

NetTopologySuite/NetTopologySuite#295

Nobody has yet yelled that the way it is implemented now imposes any problems.

It's something extra to maintain / support and something extra to think about when adding fields to types that are tagged this way. We don't have test coverage of it (at least not in GeoAPI), so there's nothing to validate that it's actually working.

If we can't quite identify the value that it's adding, then it looks like deadweight, and therefore it seems to make sense to consider removing it, which is why I brought it up.