Avoiding 403 on subobject when we can read the parent metadata.

While working with groups on the kinto-admin, we discovered [a confusing behavior](https://github.com/Kinto/kinto-admin/pull/297)

**Context**

If you have the permission to create groups in a bucket, you can read the bucket metadata.

This is a behavior that we introduced because you sometimes need to be able to read the parent metadata when you need to create a child object. For instance you want to read the bucket name to create a collection or a group but also the collection schema when you want to create a new record to build a creation form from the schema.

**Unexpected Behavior**

So the ability to create a group in a bucket gives you the permission to read the bucket metadata.
But hopefully it doesn't give you any permission to read the list of collections in that bucket.

However you can read the collection list if you have some permission on one collection of that bucket.

If you don't have any permission on any collection of the bucket you will get a HTTP 403 when trying to read the list of collections of the bucket.

**Proposal**

Returning a 403 makes sense but instead and because the user can already read the bucket metadata we could return a HTTP 200 with an empty list of collections.

What do you think?

Start by reproducing the bucket collection-list request described in the issue, using the permission scenarios from the context and the linked kinto-admin PR #297. Trace the authorization entry point for listing collections; done means a user who can read bucket metadata but has no collection permissions receives HTTP 200 with an empty list.

Written by the indexing model from the issue text.