Defer some third-party imports for quicker high-level imports

[mattwthompson]

Description

Resolves #239, for now?

I mean, we could defer loading openff.toolkit.ForceField but that seems obtuse

Checklist

• Add tests
• Lint
• Update docstrings

[mattwthompson]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.62%. Comparing base (48a65a6) to head (836583c).
Report is 13 commits behind head on main.

Additional details and impacted files

[Yoshanuikabundi]

I mean, we could defer loading openff.toolkit.ForceField but that seems obtuse

A little, but my inclination would be to do it:

• it's almost all of the remaining import time according to your graphic (if it ends up being imported anyway I wouldn't bother)
• there are some workflows in important growth areas that I don't believe need ForceField:
  • workflows importing from OpenMM or Foyer and not using any SMIRNOFF force field
  • workflows loading a previously created Interchange directly from disk (this may be important for determinism)
• the API points that need it all take it as an argument and call methods on it, so it's going to be imported by the user in most cases, which means complaints about import times will probably go to the right place

Other than that, this LGTM! I have a suggestion about indicating type aliases more explicitly that may or may not make the type checker happier but it's entirely optional.

[mattwthompson]

my inclination would be to do it

Good points, I'm convinced

Unfortunately, most of the time is spent importing the toolkit's wrapper machinery (I'd rather RDKit and OEChem not be needed until they are - separate push for a separate time)