When installing modules as part of local development, Composer
adds the files for those modules. This commit updates .gitignore
to exclude those files from the repository so we can manage those
changes more efficiently.

This repository has essentially been based in an existing `/web/`
directory. Moving most of its files to a new subdirectory will
allow us to include the files that have been one level above this.

This is part of reorganizing these files within a `/web/` directory.

Drawn from github.com/18F/cf-ex-drupal/. h/t @pburkholder

Drawn from github.com/18F/cf-ex-drupal/

Theoretically this precludes the addition of custom modules. May
want to scale back to /contrib at some point.

Brightcove API credentials have been redacted.

This doesn't include multiple instances and only covers the demo app, but
should be enough to get us started.

In an effort to closer align with the cloud.gov Drupal example, this adds a
handful of dependencies. It looks like the previous code was also built with a
generator, so this shouldn't be a big issue. All of the previous Drupal
modules should still be present.

Notably, however, this *does* declare that we're using PHP 7.1.

These are largely auto-generated, but we don't want to recreate them every
time an instance restarts, so we'll commit them to the repository.

The exception is the settings.cf.php file, which configures the database
connection, flysystem, and the hash salt based on values injected by cloud.gov
services. The values can be missing (e.g. if running locally), and a local
settings file can be used instead.

This pulls in more configuration from the cloud.gov example. It uses their
bootstrap.sh as a guide, but ends up rewriting it to leak less information and
to make use of our settings files.

It's not used and now misleading.

The uuid isn't sensitive, so we're safe to include it (it might be referenced
by other configs in the future). This also removes the nsf-brightcove module,
which we don't have anymore.

These are needed for the current config import. We'll likely remove some of
these in the future.

The "standard" install profile adds a "shortcut_set" that conflicts with our
configs, so we need to remove it. Similarly, we need to indicate that our
Drupal install is downstream from a set of configurations (by giving it the
same UUID as those configs).

This will effectively duplicate the latest config changes. It also clears the
cache, in case it'd have been affected by code/theme changes.

We'll fetch these from the "secrets" service and set them via drupal
config:override. Note that this sends its output to /dev/null, lest the
sensitive data become part of the app longs.

Edits for cloud.gov configuration