[WIP] DerivableInterfaces refactor

[lkdvos]

This is a WIP implementation of some of the things that were discussed, also in light of the upcoming DerivableInterfaces changes.

Builds on top of #31.

For now, it mostly contains a more built out version of the indexing, with a little more care towards boundschecking.
I have not yet started testing, just wanted to get an initial implementation going to allow for possible early feedback.

Notable changes:

• isstored, set/get(un)storedindex now work for cartesian, boolean and linear indices, since they have more support via to_indices and a canonical entry point
• As the AbstractSparseArrayInterface file became rather unwieldy, I split off the parts that are just generic indexing functions into a separate file
• Docstrings
• boundschecks
• no more dependency on the @derive T trait machinery

[mtfishman]

Looks like a great start! Definitely more transparent this way.

[lkdvos]

I have to apologize for the mess: this PR is somewhat growing uncontrollably.
I'm developing this in tandem to ITensor/DerivableInterfaces.jl#28 as a proof that there is no missing functionality there.
I started making some of the required changes to do so, but somehow I might have ended up bundling too many things together...

It would be great if you could maybe give your opinion on where this is going.
Notable new things here: I added an initial attempt for the "zero-preserving" functions etc, based on the discussion we had last week and the implementation that was already here.
Again, since this got rather larger, I opted to separate that out into a file.
(also, it looks like I broke broadcasting again 🎉 )
Anyways, definitely needs more work, but I think it would be good to rediscuss before this grows completely out of control.

[mtfishman]

I presumed that this would be large PR given how disruptive ITensor/DerivableInterfaces.jl#28 is. It all looks pretty reasonable to me so far, maybe it will just warrant you giving me a summary once the dust settles a bit with the two PRs. But right now the scope seems fine, unless you want to split it up into separate PRs for your own sanity.

I see basically there are:

1. updates reflecting [WIP] v0.3 refactor DerivableInterfaces.jl#28, for example making derive calls more explicit,
2. changes to constructors, and
3. changes to how zero preservation is handled in map/broadcast.

So maybe 2. and 3. could be split off into their own PRs since they look pretty self-contained.

[mtfishman]

(I forgot that the constructors are already in a separate PR, i.e. #33, so that will already simplify this PR when that gets merged.)