Handle general periodic boxes

[agrossfield]

No description provided.

[agrossfield]

I think the first step would be to create a PeriodicBox class and a subclass RectangularPrism. Calls to AtomicGroup.periodicBox currently return a GCoord, but instead should return a *PeriodicBox. Methods that consume periodic box information (e.g. Coord.distance, Coord.distance2, Coord.reimage, as well as their equivalents in AtomicGroup) would also take *PeriodicBox instead of a GCoord, and the actual reimagine would be implemented in the subclass. Each new type of periodic box would be its own subclass.

There are 3 reasons I think we should do it this way:

1. This is a breaking change, and doing it this way BEFORE we add any actual new functionality would give us time to hunt down all of the cases where periodicity gets used. The hardest part would be verifying that there aren't any codes that did the periodicity manually as opposed to using calls to reimage.
2. This also decouples us from the user-level issue of figuring out what kind of periodic box we have. Apparently, not all tools explicitly specify it (I think I recall NAMD deduces the box type from some combination of the angles specified). I suppose the easiest thing to do at least initially is require the user to specify it and just add it to the common options frameworks in the C++ and python.
3. Once we support 2 types, adding a third should be easy.