Document the correct way to manage collections to avoid security problems

Storing all related documents inside a shared collection like in a traditional database could lead to serious security problems.

Take [the first steps docs](https://docs.kinto-storage.org/en/stable/tutorials/first-steps.html) as an example, when storing all tasks inside `/buckets/todo/collections/tasks`, one could easily **broadcast** their tasks (or worse, **spam and fraud messages**) to all users in this application without prior user consent. All they need to do is setting the permission to `read: system.Everyone`.

Properly create collections for shared tasks could resolve this problem. For example, one could create a collection with a generated name for each share group, and add proper r/w permissions on it.

**This should be documented in order to pervent misusage.** And it should be noted that even if this method is adopted, server managers should also be care of possible CC attacks (by bulk-creating collections).

*I discovered this when submitting a security report to an other similar project. It has a basically same permission system while not allowing users to create seperate collections, resulting in a broken system on which you can't build literally any application. I may write a full writeup later on this.*

Start with the linked first steps documentation at docs.kinto-storage.org/en/stable/tutorials/first-steps.html and identify where collection and permission guidance belongs. Document safer per-share-group collection practices, consent implications, and the risk of bulk-created collections; done means users can follow the guidance without exposing or broadcasting shared data.

Written by the indexing model from the issue text.