ENH: use graphs for path finding, and apply new Lightpath interface

[tangkong]

Description

This is a doozy, but I think it's time to start writing some of this down.

• applies the new Lightpath interface from https://github.com/pcdshub/pcdsdevices/pull/1028/ to the BeamPath and BeamController objects
• uses this interface to represent the facility as a directed graph
  • uses simple path finding algorithms to find routes to a given beamline
  • sets out methods for handling multiple paths to the same destination
• Adds and updates tests accordingly
  • Adds a new path.json file that roughly reflects the current LCLS beamlines
• Adds LightpathItem happi container and sets up entrypoints

Motivation and Context

Lightpath in its current incarnation cannot represent the LCLS facility. This representation is hopefully more robust, and allows for new devices and beam paths to be added.

How Has This Been Tested?

• Tests have been updated, along with a more realistic test database that includes complex branching and multiple device types
• tests with real devices will have to be deferred until we update all the existing devices to match this new interface

Where Has This Been Documented?

This PR. Docstrings and type hints Pre-release notes have been added

Outstanding items

• Deal with XPP case, which does not always terminate where a branch terminates.
• Figure out best way to classify devices as upstream (compared to previous beamline-based filtering)
• Update documentation and tutorial pages
• Figure out best way to inherit LightpathItem while enabling entrypoints
• fix test suite warnings (font-awesome deprecations, in particular)
• fix test suite QThread teardown issues on TravisCI
• Add a simulated lightpath option for the GUI
• figure out how to handle devices that fail to instantiate. Currently this failure will omit the node from the graph, breaking the representation. Could we maybe create a dummy device?

(a hard-to-read visualization of the mock-facility used in the test suite, based roughly on this map )

[tangkong]

These tests are fine locally, but there's some mismatch between the happi container and path.json showing up on travis... 😢

[tangkong]

The happi error turned out to be due to the fact that the pip build does not actually install the package, meaning entry points don't get picked up. The test database therefore cannot find the lightpath.happi.containers.LightpathItem container. This was fixed by adding -e ./ to PIP_EXTRAS.

This revealed a failure to tear down QThreads in the pip test suite, which I could not fix despite all the tests passing locally without problem. PIP failures have been allowed, and the python builds limited to 3.9 (latest) to allow for more modern type hinting.

With all that, the tests pass 🎉 Not the most complete victory but a finished one

[tangkong]

I think this is ready for a more final review. I've addressed the previous items and made a slew of to-dos. For the sake of everyone's sanity, it's probably good to end this PR here.

[tangkong]

Thanks for the thorough reviews, I'm going to merge this with the intent to tackle outstanding issues in separate PR's.