Foyer Parameterization should not be dependent on package specific data-structures

[umesh-timalsina]

It might be nice to consider an the Foyer Forcefield as a generic lookup table. With #382 on the way, the actual parameters can be queried based on AtomTypes/Classes. Which means if you have a generic dictionary of system atoms and bonds, you can actually create a graph and parameterize. This will remove dependency on the OpenMM topology and System Objects to register a proper force. Since we don't use OpenMM for atom_typing and use our own logic to do it. At this point, I am not convinced that we need the internal data structures to accomplish system parameterization but I will be happy to be corrected on this point. What we might actually need is to collect all the use cases of different kinds of systems parameterized using foyer and make an assessment of what internals of an OpenMM Topology, System as well as parmed structure would be needed/replaced by gmso (loosely most of the data-structures there can be mapped to a dictionary) or an intermediary graph.

This idea germinated while working on openforcefield/openff-interchange#114 and #382 and I really like the slots based parameterization approach used by the OFF tool-chain. But, instead of using slots, we use subparagraph isomorphism based approach to identify relevant connections that would need to be parameterized (already exists in gmso). While it might be naive for me to think that system parameterization is an easy goal to accomplish based on the few examples that I have seen in our fixtures, I think the approach I describe here should be possible and might need some rehashing with domain jargon. Here's what I think a foyer workflow will end up looking like (rough might need qualification):

1. You provide a graph with atom_types as nodes bonds as edges. Foyer does the atom_typing based on that graph and some cool stuff.
2. You provide a ForceField with predefined api endpoints that foyer treats as lookup table and at the end of the workflow, foyer dumps relevant parameters. What you do with these parameters in your business, foyer shouldn't build a system/ parameterized structure for you.

Also, this would make a plugin based grammar (#377) much more accessible to external contributors where in they don't have to rely on gmso or parmed or any other intermediary package that people frown upon hearing the name of :(.

[umesh-timalsina]

The first step for this is to decouple the run_atomtyping step from the parmed structure. This might not be as trivial as it seems to be at this stage, but should be doable.