Fix bug with expanding lists of roles, compromising authorization

This pull request fixes a bug where some lists of roles in global and endpoint config (`DOMAIN`) would possibly expand for each request, leading to issues where:

 - Auth classes' `authorized` would be called with an `allowed_roles` list which included unintended roles, effectively giving access to more roles than what the configuration suggests.
 - Lists would grow without bounds, potentially for every request, potentially leading to performance issues.

More specifically, this regards the three lists `allowed_roles` (domain config), `allowed_item_roles` (domain config) and `ALLOWED_ROLES` (global config), when the more granular configuration options `allowed_read_roles`, `allowed_write_roles`, `allowed_item_read_roles`, `allowed_item_write_roles`, `ALLOWED_READ_ROLES` and `ALLOWED_WRITE_ROLES` are specified. The values from the more granular options would be copied over to the former, and would stay there between requests, continuing to grow for each request that checks roles.

Thus, the authorization in a scenario where reading and writing roles are different would fail, e.g.
```python
   allowed_roles = [], # doesn't have to be specified
   allowed_write_roles = ['admin'],
   allowed_read_roles = ['admin', 'reader']
```

In the above configuration, a request for reading (e.g. `GET`) would copy all the roles from `allowed_read_roles` over to `allowed_roles` for the endpoint. In the next request all accounts with role `reader` would also have access to writing.

This bug was not revealed in tests because read/write options were not specified. Additionally, the lists are re-initialized for every test, stopping them from growing.

I also added the role configuration to the tests of other authorization schemes than `BasicAuth`, since they run the same tests. This provoked the same errors. If this was not intended, I'll change them back.

The bug can presumably also be worked around in configuration, by specifying roles with tuples, which are immutable, instead of lists.

On a more general note, it might make sense to have the entire app config be immutable when the server is running, which would prevent other errors like this one.