Inara: Review plugin's state tracking/message queueing

Historically the Inara plugin attempted to batch up events into single messages by delaying things until, e.g. a `Cargo` event was seen.

With the worker being on a strict "one message every 35s" timer this should no longer be necessary. As such we can probably simplify some of the code in `plugins/inara.py:journal_entry()`.

Furthermore, we should also double-check what it is Inara returns if the user's API key has been sending messages too fast (it could be another program also sending), and ensure we're doing some back off/alerting of the user if it occurs.

Start in plugins/inara.py at journal_entry() and trace the worker's one-message-every-35s behavior. Check what Inara returns when an API key sends too quickly, then define completion as removing unnecessary event batching and adding appropriate backoff or user alerting for that response.

Written by the indexing model from the issue text.