refactor GRaaS web app

[owades]

The current position updates web app relies on a long series of callbacks, which should be refactored to use async/await. This is major tech debt, and is important to fix for the sake of future programmers' sanity.

[unreasonableman]

Another important aspect of a refactor is to add something like a plugin architecture to graas.js. Over time, all kinds of features, flavors and test code has been added to the module, and it's become convoluted. The latest example of this undesirable effect has been the addition of a trip inference test harness (perpetrated by, uh, me).

Plugin scripts could be loaded dynamically, along the lines of this SO answer.

This is a significant change that would likely take between 3 and 5 days, but the resulting separation of often unrelated functionality and the benefits to future additions to the module seem worthwhile.

Alternatively, functionality common between items such as plain old graas client with manual driver interaction, autonomous graas client with trip inference or block assignment, trip inference test harness, etc. could be factored out into something like a graas-common.js module, and then very thin actual clients would be implemented on top of that.

Potential functionality for graas-common.js:

• loading and handling of config data
• signing and sending of messages, in particular the frequently sent GPS updates
• wake lock handling
• handling authentication data: entering as QR code or naked PEM data, putting into and retrieving from local storage
• some UI utility code

Upon some thought, the latter approach (creation of graas-common.js and factoring out of different clients) seems cleaner and more versatile than the plugin approach.

[owades]

@unreasonableman I appreciate this stream-of-consciousness update! graas-common.js sounds like a huge relief