design and implement multi-project capability

[hburgund]

For the upcoming "Optimus Prime" Roundware app, we need to have a single generic app that can reconfigure itself based on a project selected by the user. Right now, the framework is designed to be single-project and therefore needs a few changes to make it project agnostic.

Proposed updated initialization flow

• app opens, gets location, and sends to server GET api/2/projects/available/ (this endpoint is not yet in place on server)
  • probably should do some on-boarding wrt location usage permissions "Roundware would like to tell you what projects are available in your location, so please allow us to use your location. If you prefer to not share your location, you will not be able to explore local projects, but can still explore global ones." or something like that...
• server returns list of projects (including basic project info) that are available in the location of the user
  • if no location is sent with client request, project returns a default generic project or alternatively a selection of global projects (this is a server problem; client doesn't need to worry about it)
• client presents available project names and info to the user for selection
  • if only one project available, client assumes this is the one desired and skips project selection view
  • if both geo-listen and global project are available, we may need to consider a way to distinguish between them for the users
• user selects a project from list of available, corresponding project_id is set globally within the client and the framework is spun up using that project_id
• client UI i configured using graphics etc downloaded from the server as well, but that's for another issue
• app functions just like it was a single-project app from that point forward

Notes

• framework should probably store project info in plist of last project accessed so that it can use that data if opened offline
• offline mode must be eventually considered more carefully, but for now, disallowing LISTEN, but allowing SPEAK makes sense and user should be notified of this restriction
• we need white-label capability as well: ie. the framework should have a flag of some sort so that if we don't want it to ping the server for available projects but rather have a hard-coded single project_id and graphics etc so that it acts like current RW apps
• there is no need to be able to reconfigure after framework is launched; if a user wants to choose a different available project, they must quit the app and re-open to get the project choice view