Update Rake tasks

[pyrmont]

A number of the Rake tasks that generate lists of built-in functions for particular languages have bugs. These range from actual errors (as in the case of the Lua task) to deprecation warnings (in the case of tasks using Kernel#open to open URIs).

This PR fixes these bugs and includes freshly generated lists of the built-in functions that have changed.

These changes were originally proposed in #1418.

[pyrmont]

@ashmaroli What do you think? The tasks seemed inconsistent in whether they produced output or not so I also updated them all to be silent (at least if successful). I could see an argument for standardising on a single line for each task stating that it had run successfully (alternatively, possibly something to put in the generate:builtins task).

[ashmaroli]

@pyrmont The changes here look fine. Good to have URI.open instead of Kernel#open even though these are never run by the user.
However, I'm not really sure about the test coverage of these tasks. Are they covered by the unit tests as well or just the visual app..?

[pyrmont]

@ashmaroli None of the Rake tasks have any specific tests. To determine whether they're working correctly, you're correct that it's really just the visual samples that will tell you that. That's consistent with the way the other pre-generated keywords have been handled so I think it's acceptable.

[ashmaroli]

Alrightey then.., LGTM! :)

[pyrmont]

I decided to go the whole hog and rewrite all the built-in tasks to follow the same format and, as much as possible, use downloaded files rather than static YAML files (the exception is the Matlab YAML file which I can't replace because the Matlab website is purposefully broken when accessing without JavaScript).

Despite the apparent extent of changes, most of the additions and removals are about moving code around into consistent patterns. The big exception is the VimL builtin task. The current VimL lexer uses a binary search (?) to check whether an identifier matches one of the built-in values. This is there from the very earliest version of the VimL lexer and I can't work out why it was done this way. I see no reason that simply checking the existence of the identifier in the auto-generated built-ins won't work so I did that. It seems to be working fine (indeed, the version in this PR works a little better than what we have currently because I included vimFuncName values in the auto-generated built-ins so there are more built-in values matched).