[WIP] SEC-70 - Gamma users shouldn't be able to create roles

[hughhhh]

SUMMARY

Currently users with gamma roles are still able to create roles when FAB_ADD_SECURITY_API = True, This PR is made to fix this security issue as well as add test. Reason why this is happening is due to the instantiation of the ModelRestAPI classes happening here https://github.com/dpgaspar/Flask-AppBuilder/blob/2d527aae09eed50fd52c6bf886a2970adb225428/flask_appbuilder/security/sqla/manager.py#L97

To fix it I've overriding the register_view call in manager and moving the logic to superset/initialization file. Then adding our own custom logic to only allow admin to make these request

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

# logged in as GAMMA
$ curl "http://127.0.0.1:9000/api/v1/security/roles/" \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "name": "new_role"
}'
>> 201

$ curl "http://127.0.0.1:9000/api/v1/security/roles/" \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "name": "new_role"
}'
>> 403

TESTING INSTRUCTIONS

1. Configure SuperSet to use DB authentication and set FAB_ADD_SECURITY_API = True
2. Initialize SuperSet; be sure to add an administrator
3. Launch SuperSet
4. Browse to SuperSet
5. Log in as the administrator
6. Add a new user and grant them only the Gamma role
7. Log out
8. Log in as the new user
9. Browse to the swagger endpoint (/swagger/v1)
10. Find Security Roles
11. Expand POST /api/v1/security/roles
12. Click Try It Out
13. In the Model schema area provide a name for a new role
14. Click Execute

ADDITIONAL INFORMATION

• Has associated issue: SEC-70
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[hughhhh]

@dpgaspar let me know if this pattern make sense or do you have another suggestion of either overriding the view registration, or adding security checks on the indy endpoints