optimize renovate config

[jasonkuhrt]

Agree with #410 (comment) that renovate noise on master branch is too high.

Would like to try a config that would achieve:

prod deps

• immediate PRs per major, minor updates
• one consolidated weekend PR for all patch updates

dev deps

• immediate PRs per major update
• one consolidated weekend PR for all minor, patch updates

[jasonkuhrt]

Beta feature that might be interesting to try:

renovatebot/renovate#2958

Instead of weekend PRs we can also do a living aggregate PR.

[koenpunt]

A living aggregate PR sounds like a good idea.

Also, the only updates that are actually important are patches.

Major versions should be aligned with the current state of the ecosystem. For example; a major update of graphql could make it required for users using graphqlgen to update their graphql dependency as well, otherwise there will exist multiple versions of graphql, which in turn causes issues with types being compared across versions, which will raise errors.