Defining rubocop style

This PR initially contains an empty .rubocop.yml and a freshly-generated .rubocop-todo.yml at the root.

In this PR we can discuss about each cop (disabling, enabling as is or setting parameters and variants) possibly even straight in the todo file code. I'm not going to be picky, if a cop does not make sense, it gets disabled: no need to be too stringent as it would encourage bad code.

For each decision that is taken, the selected cop configuration is written to `.rubocop.yml` and removed from the todo file, updating the PR branch.

Once the todo file is empty, it gets removed and we have our target style documented in `rubocop.yml`. At this point the goal is not to have zero violations but to have a file that will support us into making code more conformant and uniform in later PRs either automatically with autocorrect or on a case by case basis, according to homebrew's management team policies and preferences.

From then on anyway, the mere presence of the file will entice people having rubocop installed and creating new files or edit existing files fix those files one by one as time goes by.
`and` and `or` are pretty but often dangerous due to their often overlooked priority evaluation.