Integration With AdaptOctree

This issue is a description of the changes required to integrate pyexafmm with adaptoctree.

Build

Conda recipe that downloads and installs source of AdaptOctree as well as source of pyexafmm

Config should be automatic, only advanced users should need to edit these options.
Sources, targets and source densities should all be parsed from a single HDF5 db, not 3.
Interaction lists should be pre-computed, alongside m2m l2l and uc2e and dc2e operators.
points 2 leaves should also be pre-computed and stored on the HDF5 db

This method relies on the computation of the sources that correspond to leaves. This will probably be bundled with adaptoctree nodes - most likely as an index pointer.
The upward check surface is formed using the physical coordinates of the centre of a node. Not sure if this is necessary, or whether relative coordinates can be used - they should provide the same result as the geometry is unchanged, and likely to produce fewer errors.
P2P method is called from operator module to find the check potential. This is currently slow as hell, doesn't even use numba
Using np for matmul.

Specific logic correct M2M operator for each child of a given key in a uniform tree, this will have to change to accomadate the greater variety of types of M2M operator.

interaction lists again will need to be changed to accomadate different scheme.
relies on m2l operator compression, which will also have to be updated.
L2L
L2L operator precomputations also rely on specific parent/child geometry - just like M2M - these need to be updated to accomadate the greater variety of geometries.
L2P
Again has p2p calls in it, slow.

These will probably be entirely replaced, as it's specific to the non-adaptive tree.

For some reason scaled surfaces aren't precomputed for all geometries.
nor are Gram matrices....
p2p function is completely unoptimised - this is ripe for GPU treatment.
creation of objects to store potential/charge densities is actually pretty expensive. lookup costs relative to pseudo-object creation via numpy arrays and index-pointers. Same with nodes and kernel function objects.
Data loaders are not uniform in how they work, and HDF5 is being used like a file with the data base structure not being exploited. Considering how much the implementation relies on in-memory matrices, this is not being used correctly or efficiently.