Refactor neighbor lists and alphas to be more memory efficient

[kuberry]

Currently, the size of the neighbors lists 2D array is (# targets x max number of neighbors + 1). The alphas generated by GMLS have a similar, though not exactly the same, structure.

If one target site has significantly more neighbors than others, this can create quite a large amount of wasted memory. Ideally, this should be stored similar to how a compressed row storage graph is stored, with offsets into each row.

Alphas sizes are known in advance of their generation because they are directly related to neighbor lists sizes, so it is possible to switch this for alphas without creating more computational effort. However, for the neighbor lists, it is unknown at search time how many neighbors will be found, so either a.) do a search to get the number of neighbors needed, or b.) batch the neighbor search and temporarily store the batch inefficiently but then move it to a persistent location in an efficiently pack storage shape.

a.) is generally called a 'dry-run' and is already supported by the code. Currently though, it only identifies the maximum number of neighbors over all sites, which is sufficient for the current method of storage but would not be for this improved storage design.

[kuberry]

Addressed by PR #208

[kuberry]

Neighbor lists are now the same size as the sum of the number of neighbors needed by each target, and alphas similarly so. Previously they were number of targets * maximum number of neighbors over all targets.