Enable Rubocop ambiguity warnings

[pyrmont]

Rouge currently disables Rubocop's AmbiguousRegexpLiteral cop and its Lint/AmbiguousOperator. Presumably this was because of the large number of regular expressions used in Rouge that are defined using the /.../ literal syntax.

This commit prepends all regular expressions of that form with %r. It also tidies up a few uses of the *%w() construct that are present in the codebase. This allows these warnings to be turned on without causing any issues.

It should be noted that having the warnings disabled is not a problem in and of itself. However, these constructs also raise warnings when running Ruby with the -w switch. Getting Rouge to a point where it can be run with the -w switch will allow for a safer development environment.

[pyrmont]

If this PR is merged, I'm not sure what to do about the lexers that have been proposed in outstanding PRs and that don't use the %r syntax. I'm sort of loathe to ask the authors (who've been waiting so long) to go back and write their regexs in this format and yet if they don't, the Travis output is going to be a mess. Not sure what to do.

[ashmaroli]

@pyrmont My recommendation would be to merge this a.s.a.p. Then, handle the remaining warnings before tackling backlog PRs.. (#1189 reduces warnings further)

[pyrmont]

Yeah, that's probably the right way forward. I need to rebase this against master to fix the Brainfuck lexer. Should be able to do that tonight. Can then merge.

[ashmaroli]

@pyrmont I see that you occasionally use squash-merge when merging PRs. In that case, you need not rebase a PR to master. Just pulling the master should suffice. Of course it'll add a merge commit. But you can handle that at the time of squash-merge.
The advantage of this route is that the total commits of the PR in GitHub UI don't blow up..

[pyrmont]

@ashmaroli Oh, that sounds handy. So you're saying in future that I would do the following?

1. run git fetch upstream;
2. switch to my development branch (eg. git checkout <name-of-local-branch>);
3. pull master (eg. git pull master).

And that's it?

[ashmaroli]

So you're saying in future that I would do the following?

Actually no. The steps are:

# checkout PR branch
git checkout feature/branch

# Pull in changes from upstream's 'master' branch.
# Resolve any merge conflicts along the way.
# Note: This creates a merge commit if there are unmerged commits in the PR branch.
git pull upstream master

# push current snapshot of PR branch to remote
git push origin feature/branch

[pyrmont]

@ashmaroli Thank you—good to know! :)