#230 - add fallback bridge component to log events without portal

[Lance-Drane]

This creates a new bridge called "BasicBridge" which will always be created in the event of the PortalBridge not being created. BasicBridge does the same logging as PortalBridge, the only difference is that it doesn't try to talk to an IPS Portal.

Since all of the event-logging code is identical between the two, I moved all event-logging code to local_event_logger.py.

Closes #230

additional minor fixes

• fixes services.get_config_param to take an additional log parameter - in the case of a component getting the runID from the PortalBridge, we need to periodically call this function, we explicitly want an exception to be raised (we don't want to check for None), but we DON'T want to log any of the failed attempts to obtain this config parameter
• writes eventlog files to .jsonl instead of .json files; format remains unchanged, follows JSONL specification; closes Output of JSON simulation_log files use an incorrect format #185

[elwasif]

The whole logic regarding mpo is no longer needed. This feature is not used anymore and can be safely removed.

I wonder if we need to have two components who may co-exist in the simulation, one that does local logging, and one that sends events to the portal - instead of the current design which allows only a single bridge component. We need local logging to be always enabled, and the portal component enabled if the PORTAL_URL is specified

[Lance-Drane]

The whole logic regarding mpo is no longer needed. This feature is not used anymore and can be safely removed.

done

I wonder if we need to have two components who may co-exist in the simulation, one that does local logging, and one that sends events to the portal - instead of the current design which allows only a single bridge component. We need local logging to be always enabled, and the portal component enabled if the PORTAL_URL is specified

This makes sense since both of these components are heavily I/O bound, and local logging and portal interaction should never block one another. I can take a look at implementing this.