Improve support for plugin-defined features

[t-bast]

We allow injecting non-official features via plugins, by extending the CustomFeaturePlugin trait. However, we previously added those features to a set of unknown features: we can do better and add them to the known features map, which provides pretty-printing in logs and simplifies debugging.

We also had an issue where hasFeature would always return false for plugin features, even when they were supported by both nodes, because we only looked at our activated features map which only contains official features.

We get rid of the UnknownFeature class entirely and keep the encoded feature bits after deserializing them. We take those feature bits into account in hasFeature, which fixes the issue.

This creates a slightly weird asymmetry because our local features, which are created based on our eclair.conf, will not have this field set while features that are read from network messages or the DB will have this field set. A better architecture would be to remove the activated map entirely and directly wrap the feature bits, while providing helper functions to interact with features without having to directly read a BitVector. This is a larger refactoring though, because we'd need to add support for filtering init / node features using bitmasks, which isn't entirely trivial to handle and requires careful management when there are plugin features.

[pm47]

I think we should use ByteVector instead of BitVector to store encoded features:

• it saves error-prone padding
• we will always get byte-aligned bits from the network anyway
• we can always convert to bits inside our methods when convenient