feat: add arrays to IndexedStorage typings

[woutermont]

Putting this here should it be of any value. I added this for the work on UMA, but no longer use it. The typings compile and work with the CRUD operations of the WrappedIndexedStorage, but something goes wrong when using the find features. That code is rather hard to follow, though, so if we want to keep this, maybe you can take a look, @joachimvh?

[joachimvh]

The idea behind the interface of the indexed storage is to have something similar to what you would have in a SQL store, with the idea of at some point having an implementation that actually uses SQL. Having arrays as an option would sort of go against that. For multiple values it would be expected to instead have a type that stores the value, and references the type where you would want to have the value. And if you then wanted all values for the parent to use find on the new type, with the id of the parent type.

[woutermont]

Hm, alright, then I guess we can just drop this.

The use case I initially wrote this for was to load an array of keys per account from the config with the SeededInitializer. How would you do this then?

[joachimvh]

The use case I initially wrote this for was to load an array of keys per account from the config with the SeededInitializer. How would you do this then?

Have a Key type with accountId as foreign key, similar to how it is done with pods for example.

[woutermont]

Sure, but isn't that placing the burden in the wrong place? The initialiser must then process each array to put it in the storage.

Not a big issue though, since I don't need it right now. We can drop this PR.

[joachimvh]

You could then have an inbetween KeyManager class or something like that, that takes an array of keys as input together with an accountId. The IndexedStorage is expected to be the very low-level storage, with inbetween classes to provide the "expected" functions.