authorization: Update authorization rules per API

Each API must specify which requests methods are exclusive for the admin
role.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Update /login to return user roles instead of sudo parameter

For now, Kimchi just supports 2 types of user roles: 'admin' - user has
full control of Kimchi features and 'user' with limited access. But in
future the idea is to have more and more roles so it is good to
already provide the authorization support with that in mind.

That way, instead of only returning if user has or not sudo permissions, the
/login API will return the user role for each tab.

If the user has sudo permissions he/she will have 'admin' role,
otherwise, 'user' role.

curl -H "Content-Type: application/json" -H "Accept: application/json"
  http://localhost:8010/login
  -d'{"username": "guest", "password": "guest-passwd"}' -X POST

{
  "username": "guest",
  "roles": {"templates": "user",
            "host": "user",
            "storage": "user",
            "guests": "user",
            "network": "user"},
  "groups": []
}

curl -H "Content-Type: application/json" -H "Accept: application/json"
  http://localhost:8010/login
  -d'{"username": "sysadmin", "password": "sysadmin-passwd"}' -X POST

{
  "username": "sysadmin",
  "roles": {"templates": "admin",
            "host": "admin",
            "storage": "admin",
            "guests": "admin",
            "network": "admin"},
  "groups": []
}

Having one role per tab, give us more flexibility to assign different
roles to user.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Add "access" elements to tabs.xml to describe user view

Kimchi has 2 user roles: "admin" with full control of Kimchi features
and "user" with limited access
To describe how each tab should be displayed to user, an "access"
element was added to tabs.xml indicating which view mode each role has.

<access role="..." mode="..."/>

The "mode" attribute values are:

- none: do not show the tab;
- admin: full instance access;
- read-only:  read-only access;
- byInstance: each resource will have its configuration sent by the
  backend ("access" parameter);

The user will only be able to manage the guests he/she is assigned for,
because that the guest tab has 'mode' == by-instance.
That way each VM will have a new parameter "access" indicating if user has
"full" or "read-only" access to this VM.

As a user can edit a guest, he/she may need to know which networks
and storage pools are configured, so set network and storage tab 'mode'
to read-only.

And as user should not perform any operation on host or templates, set
their 'mode' attributes to 'none'.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Add "access" parameter to VM resource

As the guests tab has by-instance mode when a normal user is logged into
Kimchi, each VM resource must specify the user access.
By now, if a user has access to a VM he/she will have full access to it
so add "access=full".

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>
authorization: Get role according to tab instead of sudo rights

Kimchi will allow one user role per tab but it protects its resources
through API URIs.
That way we need to map API URIs per tab to get the user role.
Do that by adding a new parameter to UrlSubNode() to describe which tab
the URI is used.
And then use that information to get the user role for each request.

Signed-off-by: Aline Manera <alinefm@linux.vnet.ibm.com>