Add organization and location to foreman.

This feature allows foreman to provide multi location, multi tenant and
multi organizations capablities.

the idea is that resources within foreman (e.g. hosts, subnets, users,
environments etc) can belong to one or more locations and organization,
effectivily hidding resources from users.

Organization may contain multiple locations, and Locations can belong
to multiple Organization, this is an extermily flexiable design,
however, it is up to the user to allocate the resources across the
organizations and locations.

When creating new hosts, the resources that can be consumed are only
resources in which exists in both the currently used organization and location.

fixes #1578
fixes #1593
Ensure existing org user search is unscoped

refs commit:611f5bff
fixes #1976 - fix path to Puppet to /usr/bin
ensure that internal users can login correctly when orgs is enabled
ensure no duplicate hosts can be created
make sure that default join objects of taxonomy are RW
Minor optimization

Since we are looking for the ID and the join table includes the ID
there is no reason to actaully fetch the data table it self.
oops, fixed typos
ensures that admin user can't be duplicated when running within an org
Fixes bug in Puppetclass search_for by host
removed params required => from update action
fixes #1899 require HTTPS URL for oVirt API, now HTTPS-only
Taxonomy (Orgs / Locations related fixes)

* fixed edit habtm with taxonomy join.
* code cleanup
* use sub query instead of inner join, it solved all the org problems :) and perform better.
fog 1.8 has been released - updating gem file
ensure all taxonomies migration pass on pgsql as well.
Initial migration fixes for postgresql
Allow admin users to join Orgs
remove hypervisor vm info from tests refs #1957
added template_kinds controller to api
Clear the thread values outside of handling request

Adding an around filter to clear the thread values. Without this there
is a risk that the thread value from previous request will be used in
other request, which can lead to security issues.

We clear the current user at the beginning of the request (except the
test environment, where it's being used to simulate user being logged
in). In the production, this should never happen, but it's better safe
than sorry.