Support version 0.4 of SMIRNOFF vdW section

[mattwthompson]

Resolves #1678

Cribbed heavily from https://github.com/openforcefield/openff-toolkit/pull/1277/files#diff-fd6b852eaa3bb076240130325c7023d4041de6b0f45bee26c509e61b8a661a23R3839-R3890

There's a dependency loop here in which Interchange needs to parse the new attributes, but can't without the changes to the toolkit - and the toolkit's tests won't pass unless Interchange is updated to handle the new attributes. This mirrors similar issues that might happen in deployment - if (say) 0.14.2 up-converts to 0.4 but for any reason a new version of Interchange isn't immediately released to support it, most of our infrastructure is broken. I'm exploring the possibility of, prior to changes in the toolkit, having Interchange automatically down-convert 0.4 to 0.3 with the intent that a subsequent release does the opposite. Currently these conversions are equivalent in information content so the conversions are not lossy. I think this can enable a smooth transition of all moving pieces, setting the stage for future changes like LJPME, and not breaking existing workflows that rely on OFFXMLs with version 0.3.

• Update interchange to process vdWHandler.periodic_method and vdWHandler.nonperiodic_method
• Remove unused nonbonded_resolution_matrix
• Remove out-of-spec LJPME
• Tag issue being addressed
• Add tests
• Update docstrings/documentation, if applicable
• Lint codebase
• Update changelog
• Add openff-interchange-base >=0.3.10 to release builds

[codecov]

Codecov Report

Merging #1679 (f5ec529) into main (80271af) will increase coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

[mattwthompson]

Interchange 0.3.10 up-converts 0.3 to 0.4, and also supports processing 0.4 directly. Tests here should be passing using it, and Interchange 0.3.10 should still work with versions of the toolkit that do not include this change.

[j-wags]

LGTM! Thanks @mattwthompson.

[j-wags]

(not blocking) Darn... I was gonna request that we also continue supporting "PME" (just to store in-memory, even if it raises a NotImplementedError when folks try to use it), but without knowing whether it'll be called like "Ewald3D" or "PME" or "something-like-conducting-boundary", it would do more harm than good to shim it in. So I now realize that, when we start doing LJPME studies we'll need to start with a SMIRNOFF EP, then TK and IC releases, and then the studies can begin.

[mattwthompson]

Thanks for the leeway here - I'm not thrilled to reduce feature coverage (even though in this case it's unimplemented and not tested) but I think it's the right approach.

Hopefully LJPME is something we can get into the spec in short time, and hopefully it's only a small lift after 0008!

[mattwthompson]

Thanks!

[mattwthompson]

I didn't investigate the docs issues, but I did start a paper trail: openforcefield/openff-docs#21

I'm in a good mood today and investigating SetupTools changes is the sort of thing that would change that.