t422: add GUID field to vrc.ManifestCollection model + update fixtures

In the general sense, this allows us to reference and identify an Installable
Trustwrapper across namespaces (globally unique id). More immediately, this
allows us to specify the MC used to install a Private Registry.
t425: add jinja template loader, pull from django database.

intended for loading manifests as templates, so this is included
in the VRC for now, though it would likely be more appropriately
placed elsewhere (and be more accessible, it is not tied to
manifests).
t425: merge branch qa-develop >> t425
t425: correct tabs/spaces in installable tw fixture
t425: refactor vrc.models.ManifestCollection.src()

* simplified ManifestCollection.src and ManifestCollection.get_src()
  into just ManifestCollection.src()
* in pursuit of #425 [1] and likely a few others..

[1] https://redmine.idhypercubed.org/issues/425
t425: deploy private registry from manifest in db

* use a mock setting to reference the registry manifest to
  deploy, currently MANIFEST_PRIVATE_REGISTRY
* the Manifest Collection referenced is imported when deploying
  a registry (of either type), and the id is a GUID.
* use our recently added jinja template db loader to load the
  manifest source as a jinja template
* we render the template with jinja and provide a context dict,
  this is how we control what variables are in the template
* once rendered, we load the jinja-processed manifest source as
  a ConfigObj and pass along to oms_deploy()
* we no longer reference a manifest as a file when deploying
* updating manifests requires maintaining the fixtures, possibly
  working to keep an ini-formatted version in sync with our
  django fixture
* note that this is a wee bit messy and could be cleaned up with
  a few tweaks to separate out data from algorithm, and to hide
  the details you need to know to render the manifest to ConfigObj
  from jinja template
* for #425, #427, and #422
t427: set unique instance name - private registry

* YES! with the manifest loaded and processed as a jinja
  template, devs can use template variables to set values
  in the manifest at deploy-time
* atm, only one key in the context dict, {{ instance }}
* for a private registry, set the instance name to:
  registry-AAAAAAA   where AAAAAAA is a set of random chars
t425: export updated private registry manifest >> django fixture

* this fixture is used to import manifests into a registry during
  deployment
* this is for #425 and #427, and even allows a registry to be
  deployed with a unique instance name
gps demo visualization page. tracking GPS and displaying a message when proximity is near to a predefined point.
#540: Add docs to VRC's EULA resource
updated texts
updated text according to t541 - adding loading gif
updated text according to t541 - adding loading gif
t371: remove deploy_trustframework task

we have a replacement coming..
t371: remove api endpoint: trustframework/deploy/

* we are doing this differently now.. when the portal needs to
  create/deploy a new registry for a new user, we don't need to
  record much in the database. in otherwords, we have no TF
  object in the portal's db to deploy - we simply call a special
  deploy_private_registry() task.
* this is considered part of code/cruft clean up for #371 [1]

[1] https://redmine.idhypercubed.org/issues/371
t425: refine registry deploy, factor out vrc.tasks._install_trustwrapper()

* the registry is just another trustwrapper, so install it using
  a generic/common install function
* _install_trustwrapper() separates out the steps common to
  installing all trustwrappers, not just a private registry.
* this function hooks up and captures fabric's logs for us and
  returns the output (results)
* accepts a guid to specify the Manifest Collection to install, and
  a context for the manifests rendered as jinja templates
* each manifest in the collection is iterated over and rendered /
  deployed individually, not all as one call to oms-deploy
* for #425, but of interest to #371 as well
t371: better doc vrc.tasks._random_instance_name()
t425: refactor vrc.tasks.install_trustwrapper()

* use vrc.tasks._install_trustwrapper()
* deploy locally, still
* there are still problems with the name of the instance, but we
  will fix this in the future (once we devise a solution..)
* again, for #371 as much as #425
t554: fix ref to ManifestCollection model/resource

 * Manifest Collections have been called 'manifest', 'template',
   and various forms of 'manifest_collection'
 * we have settled on 'manifestCollection' - this corrects all
   references to the model/resource/uri
 * update fixtures loaded into portal and private registries
 * see #554 for more details [1]

[1] https://redmine.idhypercubed.org/issues/554/
t425: re-enable UI API POST to create trustwrapper

 * this snippet to actually POST to the new trust wrapper API had
   been disabled due to it erroring out
 * ticket #554 [1] ought to have addressed the error, and so we
   ought to re-enable the POST and re-test
 * this is primarily building towards #425 [2] and #422 [3]

[1] https://redmine.idhypercubed.org/issues/554
[2] https://redmine.idhypercubed.org/issues/425
[3] https://redmine.idhypercubed.org/issues/422