Re-organize linter file code

Let's re-organize linter file code to a common structure that shouldn't be mandatory, but we can rewrite files into so people who copy and paste existing linter code will be more likely to write shorter linter definition files. We can step through the following rules from 1 to n logically to reduce the amount of code down the minimum it needs to be.

1. Prefer writing linter functions in `ale_linters` files instead of `handlers` when they don't need to shared across multiple files.
2. Prefer `ale#Pad` for adding options to a command string where possible.
3. Prefer `%e` to get and escape the executable name in commands where possible.
4. Prefer lambdas for `executable` functions where the command doesn't need the executable except through `%e`.
5. Fix the lack of `ale#Escape` for executable names where seen.
6. Prefer lambdas for `command` where possible, and use the variable name `b` for the buffer argument.
7. Prefer strings for executables where a function is not needed.
8. Prefer strings for commands where a function is not needed.
9. Order functions in linter files in the order `Handle`, then `GetExecutable`, then `GetCommand`.
10. _Maybe_ put `s:` variables in linter files after `Handle`.
11. Ensure `ale#Set` calls are used in linter files mostly for options, and they appear at the top of files.

I do not want to make this a set of rules to follow for a pull request. I just want to do a single pass through the codebase this time and forget about it. I much prefer to just accept working code, even if overly verbose, and to compress it down later on.