Fix importData

[bendemboski]

PR #219 broke importData because importData was relying on the global-ness of the adapter index.

The fix is to remove an assumption that the import/export code was making that, while probably most of the time true, is incorrect. That assumption is that a single adapter instance is responsible for all model types, and that the adapter instance is a local storage adapter. If an application was using the session storage adapter, or was using the local storage adapter for some models and the session storage adapter for others, the import and export code would do the extremely wrong thing.

So, rather than make importData/exportData fundamentally functions of the adapter, they are now fundamentally functions of the store (via helper methods), and the store looks up the correct adapter for each model type in the data payload, ensuring that it gets/sends the data from/to the right place.

I left the importData/exportData methods on the adapters (via the mixin) to preserve backwards compatibility, in case anybody was accessing the functionality through the adapter instead of the store, but it just forwards to the same helpers as the store's importData/exportData.

Also, make sure unit tests are clearing session storage as well as local storage in case we write more session storage tests, and remove code that #219 made no-longer relevant (clearing out the adapter index before each test).

Fixes #233

[xn]

Any movement on this?

[fsmanuel]

@bendemboski Thanks a lot!

[fsmanuel]

@xn @DanLeiniger @acorncon how are you using the import/export? Via store or adapter? I think about deprecating the use via adapter...

[xn]

Store.

[fsmanuel]

Released 1.3.6