This commit introduces "Application Privileges" (aka custom privileges) to the X-Pack security model.

Application Privileges are managed within Elasticsearch, and can be tested with the _has_privileges API, but do not grant access to any actions or resources within Elasticsearch.
Their purpose is to allow applications outside of Elasticsearch to represent and store their own privileges model within Elasticsearch roles.

Specifically, this adds
- GET/PUT/DELETE actions for defining application level privileges
- application privileges in role definitions
- application privileges in the has_privileges API

# Conflicts:
#	x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportHasPrivilegesAction.java
#	x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/action/user/TransportHasPrivilegesActionTests.java

The ApplicationPrivilege class had a dual purpose of defining
application privileges as stored in the security index, and also being
the means by which those privileges were tested against roles.
This made the class difficult to work with - in particular validation
was dependent on which purpose it was being used for.

This commit splits the index storage part into a new
ApplicationPrivilegeDescriptor class

# Conflicts:
#	x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/action/user/TransportHasPrivilegesAction.java

The was a spurious toLowerCase in the privilege check that was left
over from a previous design approach

* Allowing the kibana system role to get/put privileges and roles

* Removing the ability to get/put roles

* Removing unnecessary white-space

# Conflicts:
#	x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authz/AuthorizationServiceTests.java

The serialization methods for `PutRoleRequest` did not handle the
applicationPrivileges array.
Fixes this and added tests

This extends the validation for application names to allow an optional
suffix of "-" (or "_") followed by any number of "filename safe
characters" (excluding '*')

The purpose of this is to support multiple kibana instances against a
single ES cluster where the name of each kibana application is
"kibana-${kibana-index}", assuming some reasonable limits on the
Kibana index name.

The change also retricts the wildcard handling of application names
to only support a trailing wildcard: e.g `*`, `kibana-*`, etc.

# Conflicts:
#	x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/security/authz/permission/Role.java
#	x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authz/store/CompositeRolesStore.java

This lays the foundation for OLS on cluster privileges as it means
that a cluster permission can be applied not just to actions, but also
the objects being acted upon by the request.

This commit adds a test for the most basic function of the `CompositeRolesStore` which
is to merge 2 simple role descriptors into a single role. There were a lot of tests around
FLS/DLS and custom roles providers, but nothing for the most simple case.

A conditional cluster privilege is like the existing cluster
privilege, except that it has a Predicate over the request as
well as over the action name.
It is the "role descriptor" level representation for the newly
introduced "ConditionalClusterPermission"

This change adds the ConditionalClusterPrivilege interface, and
allows them to be attached to RoleDescriptors, but does not provide
any JSON/XContent support. This means that they cannot be used in the
Roles API, nor are they stored in the security index, but they can be
defined by custom Roles Providers and will be consulted as part of
authorization decisions on Roles.

This includes support in the Roles API and for storing in the security
index.

Traditional, action-name cluster privileges are still described by a cluster: []
element in the JSON, while conditional privileges are described in a policy: {}
element (the name is subject to change).

For the roles API, and builtin roles providers (native + file) the only supported
conditional privilege is ManageApplicationPrivileges represented in JSON as:

"application" : { "manage" : { "applications" : [ "my-app",  "app-*" ] } }

which restricts the use of the Get/Put/Delete Privileges actions to those that act upon the specified application names ("my-app", "app-*")

The kibana_system role can only manage privileges for applications
named "kibana-*".
The default kibana instance will have an application name of
"kibana-.kibana", and other instances will be named similarly but with
the ".kibana" replaced by the name of their kibana index.

* Changed kibaan_user and kibana_dashboard_only_user to use the app privs

* Fixing ReservedRoleTests

* Fixing some style issues with the tests

* Adding the action to the patterns if there are no descriptors

* KibanaUserRoleIntegTests now inherits from NativeRealmIntegTestCase

This causes the test to properly close the security index in the @after
to ensure we aren't leaving the .security index open

* Switching the AuditTrailTests to use monitoring_user

This way the test doesn't transiently load the .security index because
it has application privileges and need to close the index when it's done

* kibana_user can no longer create indexes, or index documents

* Deleting unused imports

* Assigning both index and application privileges

* Fix line length

* Fix bad merge

* No longer adding privilege to actions when it has no actions

* Putting test back how it was

The javadoc and validation for ApplicationPrivileges supports the idea
that a privilege could have no actions. However, in that case every
privilege that had no actions grants every other action-less privilege
within the same action, including the NONE privilege.

This commit makes the following changes:
- It is not possible to PUT a privilege without any actions
- A permission with no actions, never grants another privilege even if
  that privilege is also a zero-action privilege (which, ideally would
  never exist, but can occur through missing privileges or index
  manipulation).

The rest tests require that any request that supports GET with body
must also support GET with source="..."

This changes the _has_privileges rest action to support the source
parameter as an alternative to reading a body

The "global" field stores cluster privileges that have a richer
privilege model than the traditional "cluster" privileges.

This commit renames the JSON field (in the API and security index)
from "policy" to "global"