Rethink serialization

[tnull]

We started off reusing the same approach towards serialization as upstream LDK and planned to also reuse the macros in #23. However, as this is always a pain point upstream, we should rethink whether we really want to take the same approach.

In particular, can we create a different approach towards serialization in which:

• All fields are not only length but version-prefixed
• The type as which they are serialized is explicitly stated to make any difference to the data type transparent.
• Migrations between versions have to be explicitly implemented for clarity and hopefully even type checked?

[tnull]

Matt gave some thoughts in #10 (comment). In particular, he brought up that we may not need/want forwards compatibility, which should make things quite a bit simpler

[TheBlueMatt]

Yea, but it needs to be a deliberate decision - not allowing forwards-compat (ie not allowing users to downgrade to a previous LDK version if they have issues) is a big drawback for users, but we have to weigh that against the support complexity.

[TheBlueMatt]

When we decide if ldk-node supports downgrades we should also revisit #10 (comment)

[tnull]

Our persister should allow to specify a secondary location for backups.

[tnull]

After a long time debating the pros and cons I ended up deciding that it's not worth the effort of reimplementing serialization in a different format. LDK Node post 0.1 will therefore stick with upstream's serialization framework, format, and forward+backwards compat guarantees.

However, we should eventually offer optional serde support for public types (#75) and will document any compat changes in question explicitly in a doc (#74), which will should allow us to clean up the codebase when possible.