Configuration settings for integration testings.  A mix between
development and production, using production as a base and pulling in
specific options from development where appropriate.

`ENV['CYPRESS_DEV']` can be used as flag to enable more debugging
settings where needed.

The `sync_config` code assumes memcache, so for now just skip if in the
`Rails.env.integration?`

This is a poor solution long term since this causes issues when trying
to run integration tests against an "Integration ENV appliance", so this
should be addressed to work in a different way.

Adds an integration group for dependencies that need to be used for both
integration tests and "regular tests"

Allows them to be reused.

When calling `evm:compile_assets`, allow it to be called from a plugin
so that repos like the UI can compile assets from the plugin repo
instead of the `manageiq` repo.

Helper tasks that is used to run the necessary MiqWorker components for
running integration tests.

CYPRESS_DEV
-----------

Note on different modes:

- no `CYPRESS_DEV`:  "prod mode" where assets are static (CI, "faster")
- w/ `CYPRESS_DEV`:  dev mode where javascript assets might be edited

When using $CYPRESS_DEV, it is assumed that the user is modifying specs
or what they are testing, so being able to change those without having
to re-compile is ideal, but on CI, compiling should be a speed up for
the specs overall, and more "production like".

This is a hidden feature for now, but it is just a low cost way to
include support for multiple workers.  Easily removable if we don't like
it.

We `gzip` compress assets via `webpack`, so this "should" be
unecessary... need to confirm.

When doing `rake :env`, the `config.paths` method has already been
called/memoized when the `config/application.rb`, so that causes the
following to be called:

    paths.add "config/environments", glob: "#{Rails.env}.rb"

Which even before `:env` has a chance to run, it will set the `:glob`
attribute to the "default `Rails.env`", which in turn only allows
loading the include `developement.rb` when the initializer to load the
environment config for `Vmdb::Applciation` is finally trigger.

While not the best of solutions, I prefer it to having to have super
long commands like this:

    $ RAILS_ENV=integration rake integration:seed:db

Where `integration` is implied by the task itself (and helps "codify"
workflows).

While working through and debugging the previous FIXUP commits, this
came up as something to try, but not sure if it is needed.  Might go
away, but trying to commit/push what I have so I can transition to
working on something else.