Clarify the importance of NOINHERIT to properly create a role on the DOCS

When a ROLE is created in PG, it may inherit privileges from other roles. It specially inherits all privileges from the PUBLIC role.

[From the DOCs](https://www.postgresql.org/docs/9.5/sql-grant.html):
"Any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to PUBLIC.".

If your application is implementing a whitelist logic (most of the cases), this may represent a leak of authorization. So all roles must be created using the NOINHERIT clause, but there is another gotcha: creating a role and them altering it to NOINHERIT is a safer option than creating a role with NOINHERIT.

```
-- OK if there is no graphile_visitor already in your system
CREATE ROLE graphile_visitor NOINHERIT;

-- A better option, specially during development if you use dropdb to "reset" your application
CREATE ROLE graphile_visitor;
ALTER ROLE graphile_visitor NOINHERIT;
```

When a ROLE is created, it's not stored into the database itself, but inside a private catalog called pg_user. If graphile_visitor by accident was crate without the NOINHERIT, dropping the database won't erase it, so adding the NOINHERIT to its creation clause afterward will have no effect at all.

```
-- this is a mistake
CREATE ROLE graphile_visitor;

-- this isn't a bug fix
CREATE ROLE graphile_visitor NOINHERIT;
```

This happens because, when it runs the second query, PG will identify that a role with the same name already exists so it will skip the CREATE ROLE. Keeping creation and alteration separated will ensure the intended behavior.

Start by reviewing the PostgreSQL GRANT documentation linked in the issue and locate the corresponding role-creation guidance in this repository. Clarify the NOINHERIT behavior, role persistence, and the separate ALTER ROLE example; done means the documentation accurately explains the authorization risk and avoids implying that a later CREATE ROLE changes an existing role.

Escrito por el modelo de indexación a partir del texto del issue.