Fix Serialisation of BIP32 Keystore

[podkovyrin]

Be aware that this change breaks backward compatibility.

fixes #257

[skywinder]

About the compatibility I will bump a major version. Thank you for mentioning this.

[skywinder]

@podkovyrin is there any idea, how we can make internal migration from the old address-path storage version?
I would love to increase this bounty or create new for this feature 👍

[skywinder]

Thanks, that's how it should looks like. Just want to porpose to make smooth experience for existing users and add migration function at init + deprecated flag for old parameter.

I apreciate quality and amount of your work. And if you will done thins migrations I would be glad in increase at least 2 times this bounty. 👍

[skywinder]

This struct works much better. great design 👍

[skywinder]

My idea to set this variable as deprecated:

@available(*, deprecated, message: "Please use addressStorage instead")

[podkovyrin]

About the compatibility I will bump a major version. Thank you for mentioning this.

Another important thing worth mentioning that v3 is compatible with Eth Keystore Format used across multiple wallets. In my case, I didn't care about that compatibility but for some, it might be a serious issue. As a workaround, an importer/exporter can be introduced which would solve the migration problem at the same time. Also, it's probably a good idea to name this version like 3-web3swift or anything which wouldn't conflict with future versions of Eth Keystore Format.
Regarding conversion to the new format, it's impossible to decide which address should come first on the lib side unless we sync the blockchain headers. I would say this requires input from the library user or the end-user itself otherwise, we end up with another issue. So there should be an explicit migration strategy of dealing with sort order.

[skywinder]

@podkovyrin well, your’re right, it's impossible to predict order from old version.

But it would be possible and good practive to migrate them in any order, so developers can update the version without refactoring (and writing migration in their own code).

[skywinder]

so, there are 2 options on your choose @podkovyrin:

1. since it's develop branch, we are able to make another bounty for that and I will merge this one
2. made migration in this PR, and I will double bounty for you

[podkovyrin]

Whatever :) This migration is quite time-consuming and I would make it in a week or two.

[skywinder]

Agree. Well, I like your style and agree that it takes time.
I will increase bounty x3, but prefer to reserve it for you in one single PR for consistency. 👍
And thank you again for the help!