* Added `capi.request.<endpoint>` killswitches at appropriate call points.
* Added `eddn.capi_export.<type>` killswitches. This allows for killing
just the EDDN export of such CAPI-derived data, without stopping the actual
queries, as other plugins/functionality might still have harmless use of
the data.
* PLUGINS.md: Actually describe the contents of `data` passed to plugins, and
point out it might not always contain market or shipyard data. This is
not only because of the new killswitches, but could already have happened
if the station/port docked at didn't have the services.
* Some misc typing cleanups.
* Additional Allowed Imports `from companion ...`.
* Plugin authors will still need to chain `cmdr_data_legacy()` to calling
`cmdr_data()`, but with sanctioned access to `data.source_host` they can
then determine the galaxy data source.
* Re-worked the documentation for CAPI data a little to make all of this as
clear as possible.
* This did, however, remind me that the `data` passed into `cmdr_data()`
is an amalgam of `/profile`, `/market` and `/shipyard` queries.
This means that the data.source_endpoint is **not correct for all of
the data and its use**. As such I had to pass 'hard coded' values into
the function from the various CAPI export functions. They know what it
is they're exporting.
* As this reminded me that "CAPI `data` is actually a `CAPIDATA`", I've
documented that in PLUGINS.md, but with a dire warning against relying on
any of the extra properties.
A few bits of example code tweaked to be more correct, but to make
PyCharm truly happy about the file we'd need to expand the examples to
stupid proportions (extra imports, indent changes etc).
* Surprise! The new event is `BackPack`, not `Backpack`, although the
filename *is* `Backpack.json`.
* Store the loaded JSON dict in `monitor.state['BackpackJSON']`. That
`p` is lower case to match with the filename, not the event name.
* Document this in PLUGINS.md.
Unless EDSM is telling us to discard this we should now be sending it.
