Adds 2 new permissions related to bulk user registration and bulk channel creation.  Permissions are assigned
admin role.

The nimble:restivus package, used by REST api, does not support alanning:roles with 'groups'.  It doesn't even
use the alanning:roles API to check for roles.  As a workaround, I removed restivus's rolesRequired check from
the bulk api methods and added Rocketchat.authz.hasPermission checks.

based authorization

Leverages alanning:roles package to associate a user to a role.  Uses
alanning:roles optional "group" parameter to limit the role's scope to
either the global level or room level.  The global level is applicable
to users that can perform administrative functions.  The room level is
applicable to users that can perform room specific administrative
functions (like a moderator).

A role can have zero or more permissions.  Permissions and their
association to roles are defined by this package

Authorization checks are based on whether or not the user has a role or permission.

The roles, permissions, and their association are statically defined at
this time.  Eventually, there should be an API to dynamically create a
role and associate it to static permission(s).

Old 'isAdmin' and '.admin is true'  checks have been replaced with
corresponding hasPermission authorization checks.  Additionally, code
that automatically assigned admin privileges are updated to assign
'admin' role instead.

channel/direct message/private group code checks authorization to edit
properties (e.g. title) and edit/delete messages (regardless of the
system level allow edit/delete settings).
- user with 'admin' role are authorized to do anything
- room creator is assigned 'moderator' role that can edit the room and
  edit/delete messages
- members can only edit/delete their own messages IF system wide
  settings permit them to.

v19 migration will
- add 'admin' role to users with admin:true property
- add 'moderator' role scoped to room for room creators
- add 'user' role to all users.

There are known issues unrelated to the changes made
- If a user with edit/delete message room permissions logs out then a user without
  edit/delete message room permissions logs in, then they will see
edit/delete icons.  The server will deny execution
- edit/delete icons are not reactive   Thus if the system level allow
  edit/delete message setting is toggled, the icons will not reflect it.
The server will deny execution.