Improve `espaloma` Support

We should update the default espaloma ff to espaloma-0.3.2.pt

Espaloma 0.3.x is supported, we have run simulations using it for both protein and small molecules. That said, the way to use it is probably not that easy to accomplish, we should make this more streamlined.

We had specific GHA workflows to test the espaloma support but I don't know why or when these were removed. Sounds like we should get these back.

I'm curious the use cases of Espaloma with this package vs. just using Espaloma's API directly to generate parameters (in the form of an openmm.System)? I can only think of

Experiments using Espaloma for one portion of a topology and another force field for another portion
Similar to above, but using a non-Espaloma on chemistries it's not suitable for

The current architecture of building something on top of SystemGenerator (which itself has a lot of magic built on top of these templates) which parses Espaloma data to eventually get a system - compared to just getting it directly from Espaloma's parameters. It may be that rewriting downstream code to use Espaloma's API is not so simple, I'm not sure

They were just consolidated into a single CI file, I said "improve" espaloma support since for the end-user it looks like we only support once espaloma ff, I will update the issue instead to update what we consider the "default" espaloma version (just like we updated the default openff version)

openmmforcefields/openmmforcefields/generators/template_generators.py

Lines 1801 to 1807 in f943979

    
           def INSTALLED_FORCEFIELDS(self): 
        
               """Return list of available force field versions.""" 
        
               # TODO: Does this belong here? Is there a better way to do this? 
        
               # TODO: Update this 
        
               # TODO: Can we list force fields installed locally? 
        
               # TODO: Maybe we can check ~/.espaloma and ESPALOMA_PATH? 
        
               return ["espaloma-0.3.2"]

They were just consolidated into a single CI file, I said "improve" espaloma support since for the end-user it looks like we

Ah I see, what I saw is that the espaloma tests are being skipped. I set these tests to be run with the --runespaloma flag, we should probably add that to the pytests flags or remove the requirement for it. At the time this was designed in such a way because the espaloma tests were optional and we only wanted to run the espaloma tests in that specific CI workflow.

I'm curious the use cases of Espaloma with this package vs. just using Espaloma's API directly

@mattwthompson This is a good point to raise. As far as I can tell, we do want to maintain the possibility of using Espaloma only for specific portions of the topology (be it only the small molecule, or a mutant residue, a cofactor, etc.). However, I agree that the current approach is very cumbersome and hard to maintain in the longer term.

	def INSTALLED_FORCEFIELDS(self):
	"""Return list of available force field versions."""
	# TODO: Does this belong here? Is there a better way to do this?
	# TODO: Update this
	# TODO: Can we list force fields installed locally?
	# TODO: Maybe we can check ~/.espaloma and ESPALOMA_PATH?
	return ["espaloma-0.3.2"]