Modernize lexers

[mcepl]

Partially fixes: #76

Will add more fixes to this branch, help (and PRs to my repo) is more than welcome!

(@orbitalquark , feel free to partially merge commits in this PR, but please don’t close it yet, I will happily rebase on the current default and continue with more lexers).

[orbitalquark]

I appreciate your zeal on this initiative, but it's not as simple as it seems. I could write a script to follow the migration steps mentioned in #76, but that's not the point. As mentioned in that issue's description, this is an opportunity to:

1. Distinguish between functions, builtin functions, and methods.
2. Distinguish between constants and builtin constants.
3. Distinguish between variables and builtin variables.
4. Use pre-defined tags where possible, or consider adding new ones.

Also, we should see if any word lists need to be added or updated, or if the language has added new features the lexer doesn't support.

I imagine for each lexer this will require research and careful thought. I don't feel that there is a point in applying the migration steps just for the sake of doing so because (1) it's just busy work, and (2) these legacy lexers still function properly. I'd like to think that a migrated lexer is complete and current for its language.

That said, I will not try and dissuade you from this task :) Just please keep in mind there are criteria I have for acceptance.

[mcepl]

I understand that such mass change will never make the perfect results, but I believe that it is better to do this yes largely a busy work (not only, I do overview each lexer, and some of them are substantially improved, like my rpmspec, which I use daily) and get it out of the way. Problems with each individual lexer would be IMHO better suited for separate issues and pull requests each. As a former PhD sociology student, I am a firm believer in the “broken windows theory” and I believe that neglected issue tracker breeds more neglect and seemingly unhealthy project doesn’t generate interest of potential contributors. And yes, I was working for years as a bugmaster on a large Bugzilla, so I am a bit anal-retentive in having issue tracker neat and clean.

[mcepl]

I will rather split into individual PRs, easier to review.