CAPI/Plugins: Add support for Legacy CAPI data

[Athanasius]

As of Update 14 the usual CAPI host/endpoint only returns Live data. To retrieve Legacy data we will need to query https://legacy-companion.orerve.net/ instead.

To support Legacy players we will need to query the correct host/endpoint so that data is correct for:

1. EDDN messages sourced from CAPI data (auto update on dock, or manual 'Update' whilst docked).
2. File > Status data (listing of all the Cmdr's ships).
3. Data passed to plugins.

Data sent to EDDN

Currently we're only sending Live data, with a gameversion of CAPI-<endpoint>. The fact that we're not sending any Legacy data is known for EDMC 5.6.0.

We can't start sending Legacy CAPI data until a change to the EDDN schema documentation has been agreed. We would then need to update what we send for all CAPI-sourced data so it's 100% clear not only that it's CAPI data (not Journal), but also which Galaxy it is for.

---

File > Status

This is simple. Currently Legacy players get no data (and using this menu entry fails silently). Once we are querying Legacy data it'll simply be the cached data and this should work.

---

Data passed to plugins

Given the current function signature of cmdr_data() we can't add any new arguments to it in order to denote Live versus Legacy. We could technically add a field into the data passed in, but I'd rather not muddy the waters of that (it's already bad enough with it being a merged set of CAPI /profile, /market and /shipyard data).

So, instead I propose to add a new plugin API function cmdr_data_legacy() to receive Legacy CAPI-sourced data. This also has the effect of any plugin only concerning itself with Live CAPI data needing to make no changes.

I'm also open to the idea of a cmdr_data_live() alias for cmdr_data(), with the former being preferred (if it's found it gets called and cmdr_data() doesn't). This would mean cmdr_data() being deprecated. There's an argument for removing it ASAP to protect plugins against blindly trusting the data as definitely being relevant for a Cmdr, but we should be able to take care of that through only querying the correct host and calling the correct function.

[A-UNDERSCORE-D]

yeah a legacy one works for me. I dont think theres a simpler solution than offering an optin function like that

[Athanasius]

Yeah, the issue would be suddenly dumping Legacy CAPI data on plugins where they haven't previously had any method to discern the source.

Check #1747 mentioned above. Given I added CAPIData.source_host (as we already has CAPIData.source_endpoint for internal reasons), and I've now documented that as being valid for plugin use, they can all just end up doing what I did in plugins/eddn.py in that PR - chain the call to cmdr_data_legacy() through to cmdr_data() because the latter checks data.source_host as needed.

So:

1. Plugins only interested in Live data need make no changes.
2. Plugins only interested in Legacy data (hey, it might be a thing), can just rename their function.
3. Plugins interested in both Live and Legacy data can either chain the calls if the difference for them is minimal, else implement cmdr_data_legacy() however they need to.

[Athanasius]

Now in released 5.7.0.