Neighborlists in TorchScript models

[chrisiacovella]

Currently, when we set up a Potential, we pass to the constructor the neighbor list. That means if we wish to change the neighbor list strategy (e.g., brute vs. verlet or any parameters therein), we need to instantiate and save a new version of the potential.

Since part of our current plan is to distribute models as .pt files, rather than instantiating a class and loading in parameters (as this would require having modelforge be a dependency), this would require a separate pt file for all variations we might have, which is probably less desirable.

While there are numerous ways we could address this, but I think the least disruptive approach is to merge the inference neighbor lists into a single class. The brute force neighbor list is simply just the verlet list with a rebuild time of 1 and skin = 0 (although can also just put in some logic statements to switch which routines). Even a cell based backend is simply just a modification to how we initially build the set of possible pairs.

We can have a default strategy and allow users to set the strategy at runtime (e.g., via the constructor of the wrapping class designed to work with openmm-torch).