ui: Implement read-only KV/Session and Intention views based on ACLs

[johncowen]

This PR is a continuation of #9687.

Here we implement read-only views for KVs, Sessions and Intentions based on your ACL Tokens policies.

This means you can assign ACLs to users in the UI giving certain users read only access to areas like KV. This is currently at a global level using something like:

key_prefix "" {
  policy = "read"
}

which would give the user with a token with the above policy read only access to all KVs.

Being able to configure this more finely per KV will be added in a further PR.

Further notes:

1. {{disabled}} modifier f0cc8cb. <fieldset>s have a nice feature that lets you set a <fieldset disabled> on them which means all of the form elements within the fieldset are in a disabled state, meaning you only have to set the disabled-ness in one place. The downside is, if you want everything disabled apart from one form element, there doesn't seem to be a native way to do that. Using a modifier instead means we can add the functionality we want here. This is currently not super reactive (if you add further elements to the parent element after insertion these will not be set to the correct value for disabled). In order to improve this we'll probably require some MutationObserver work. As and when we need that we can look at that then.
2. Global configuration of protected routes 66c8cc9 and e66c220. We currently have a JSON-like object which is then used by Router in order to create embers routes. This means we can also use this information for other things, for example knowing whether a route is a wildcard route in order to add further url de/encoding logic to the params for this route. These commits further add to this configuration with an abilities: [] property. The abilities property allows you to use ember-cans DSL to specify what abilities a user requires in order to access a route. If the user doesn't have all of the specified abilities then they see a 403 page instead. Using the central configuration means we can add the logic required for this to our Consul specific base Route, then its super simple to see all in one place, what routes have additional ability based restrictions.
3. Acceptance tests where added, along with a new step to allow us to set a users permissions during testing. Worthwhile noting that in order to set permissions during development the cookie names to use in WebInspector takes the form CONSUL_RESOURCE_{singular-resource-name}_{access_type}, so for example setting the cookie CONSUL_RESOURCE_INTENTION_WRITE=false will give you readonly intentions.

[kaxcode]

LGTM 🎉