Split Blue specific IP out from core codebase

[martintoreilly]

Goal

Core Science Gateway codebase must be publicly shareable without compromising each client's IP. Clients must also be able to generate new features/components without having to commit them to the main public Science Gateway repositories.

Acceptance criteria

Client-specific code are not present in the public Science Gateway repositories: client-specific code includes:

• [ ] all simulation specific files and custom action word backend scripts (RUN, PROGRESS, etc)
• [ ] Case templates
• [ ] Configuring job managers (from general Azure + PBS versions) [Q: Do we want to support custom job managers]
• [ ] BLUE instance can be deployed with a specific version of the core deployment
• [ ] Synchronised versions (issue #22)
• [ ] custom three.js front-end data models (for Blue this is the Tank and Pipe)

Sizing

• 40 for custom front end
• 13 for the rest

Implementation notes

• In interim make the repos with private Blue stuff private
• Some research and reasoning demonstrating whether the repo/sub-repo model is the best way to achieve the goal above
• Client specific code to live in private github repositories
• Core Science Gateway code is pulled from a sub repo (inversion-of-control thinking so that public Science Gateway updates aren't forced onto the client deployment -- updates can be pulled at client's discretion)
• Do we want to split out Gmesh loader as BEM++ specific element? Make separate ticket for BEM++ stuff.
• For simulator specific files, case templates and run managers we can probably do this purely from config.
• We don't have a good approach to make the front-end UI "pluggable" with private custom elements

[masonlr]

Removing this issue from Sprint 2.2 due to current focus on OpenFOAM development.