* Need to remove `event`, `horizons` and `odyssey` per signal.
* It's lower case `horizons` and `odyssey` in a(n augmented) journal event.
* It's `event`, not `entry` that `export_journal_entry()` will look for.
* Move call to `export_journal_fsssignaldiscovered` to top-level of event
processing. This ensures we'd still have the *previous* system tracked
when running under Odyssey.
Also, we can't return any result from this, as we'd still need to process
things like `Location` otherwise.
* Use `logger.trace_if("plugin.eddn.fsssignaldiscovered", ...)`
* Perform all sanity checks, elisions and augmentations in the "not
FSSSignalDiscovered event" sending code.
On checking, all of the events valid for the journal schema (and CodexEntry
has its own schema and separate EDMC code) already contain SystemAddress, so
it would never be added as an augmentation.
Instead, turn this into a sanity check.
* A login-time `ApproachSettlement` happens before `Location`, if
appropriate.
* Also add a future comment about FSSSignalDiscovered, for if EDDN ever adds
the schema.
It turns out some of the other strings, that do not have minLength=1 in the
schema, can be empty and that's OK. i.e. NearestDestination.
So, let's only check for the actual minLength=1 things. Which is a few
top-level key:values, and then the contents of the Traits array.
* Call it system_name in `export_journal_fssdiscoveryscan()`, as `system`
could be amigbuous.
* Might as well use `system` passed in to `journal_entry()` when calling
`export_journal_approachsettlement()`.
1. We need StarPos (as well as StarSystem)
2. Adding more state tracking in this plugin is misguided.
3. So added it in monitor instead, putting *copies* of data in the
monitor.state dictionary.
4. So we reference those, but only available in journal_entry() itself, else
we'd need to pass the whole of `state` in.
5. So instead pass in the bits of `state` only when we need them.
Also, whilst the *current* code has the 'augment files' handled last in
then if/else tree we shouldn't assume that will always be the case.
So, be paranoid and use different variables for the augment-loaded entry
and its .lower event_name.
'cos you just know one of us will trip up on it later if there's ever some
'finally' code after that conditional tree.
