Don't erase %{app_root} during %pre

Here's roughly what is happening here

- RPM is asked to update aeolus-conductor

- As part of the transaction, RPM checks the status of settings.yml.
  RPM finds that (1) settings.yml is marked as %config in the spec
  file, (2) settings.yml as shipped with $new_version contains the
  same content as shipped with $old_version (it ignores the contents
  of the file as it exists on the filesystem), and (3) settings.yml
  has local modifications (via aeolus-configure).

- Because of 1-3 above, RPM marks settings.yml to be skipped during
  the transaction.

- The %pre scriptlet runs, and removes %{app_root}, which in turn
  removes settings.yml.

- Because the transaction has already decided to skip settings.yml, no
  action is taken on it.  At this point, the file is gone.  RPM will
  not lay down the file as it exists in the RPM, nor will it produce
  any sort of .rpmsave or .rpmnew file.

Related bug:
860822 - aeolus-conductor RPM upgrade deletes settings.yml
https://bugzilla.redhat.com/show_bug.cgi?id=860822
BZ #861941: fix lowercase back button on deployments#launch_time_params

https://bugzilla.redhat.com/show_bug.cgi?id=861941
BZ860314 Added deployments properties translations

https://bugzilla.redhat.com/show_bug.cgi?id=860314
Add an rvmrc file to the project.
Cucumber features for upcoming Catalogs API

All features are marked as @wip and will be unmarked as the features get
implemented.
Routes and #index for Catalogs API

RM3579

Routes for Catalogs API added.

List catalogs action (#index) implemented, rspec'd and cucumbered.
Catalogs API #show action

RM3580

Implemented, speced, cucumbered.
Catalogs API #create action

RM3578

Implementation, specs, cucumbers.

CatalogsController gets a before filter to transform incoming parameters
for #create and #update from:

    :catalog => {
      :name => '...',
      :pool => {
        :id => '...'
      }
    }

to:

    :catalog => {
      :name => '...',
      :pool_id => '...'
    }

Loading catalogs' deployables was previously used only in #show action,
now it is used in #create as well, because API version of #create
renders the same thing as #show. Therefore, loading deployables has been
extracted into private load_deployables method, similarly to a
load_pools method which is already present in CatalogsController.

One shared RSpec API expample is added to allow testing for `201
Created` response status conveniently.
Catalogs API #update action

RM3581

Implementation, specs, cucumbers.

In #update action of the controller, the permission check for altering the
catalog's pool association was changed. Previously the check was performed
always, this was causing problems when updating with just partial
representation of the catalog (when pool_id was not specified at all).  Now the
check is performed only if pool_id is present in params.
Catalogs API #destroy action

RM3582

Implementation, specs, cucumbers.
Add Catalogs API to entrypoint

RM3796
Add catalogs listing to Pools #show API action

RM3695

Also added a new FactoryGirl factory - :pool_with_catalog
Check permissions when listing pool's catalogs

PoolController #show action listed all pool's catalogs. Now it lists
only catalogs that current user is permitted to see. (Currently, this
should mean no practical difference, as if a user is permitted to see a
given pool, they're also permitted to see all it's catalogs.)
BZ859998 disable certain fields from editing if in ldap mode

Signed-off-by: Matt Wagner <matt.wagner@redhat.com>
Merge pull request #80 from jeckersb/bz860822

Don't erase %{app_root} during %pre
Merge pull request #88 from jistr/catalogs_api_rev1

Catalogs API
BZ #862295: fix back link on deployments#launch_new

https://bugzilla.redhat.com/show_bug.cgi?id=862295
Merge pull request #93 from ifarkas/BZ862295-context_aware_back

BZ #862295: fix back link on deployments#launch_new
BZ861418 display useful image uuid information on details page

Signed-off-by: Matt Wagner <matt.wagner@redhat.com>
Fix backwards logic in Provider.valid_framework?

Looks like this got reversed in 598c9e9b; it causes adding new
providers to fail.  Just return the truthiness of connect!, since it
returns the client object if successful.