Add options for targeting allowed PHP language features and functions

At least in the case of WordPress, there is a very wide range of PHP versions that may be running. For use in its built-in file editor, there is a need to try to prevent users from accidentally introducing fatal PHP errors on their sites. One major source of such fatal errors is accidentally using a language feature from a “recent” PHP version when WordPress is running on an old version of PHP (version 5.2 is still supported). A recent example I came across was attempting to pass a function into `empty()` which is a fatal error before PHP 5.5. In other words, this is essentially porting the [PHPCompatibility](https://github.com/wimg/PHPCompatibility) sniffs for [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer) into php-linter.

While we are working on server-ride solutions to actually try running the code and then rolling it back if there are fatal errors (e.g. [#39766](https://core.trac.wordpress.org/ticket/39766) and [#21622](https://core.trac.wordpress.org/ticket/21622)), it is naturally highly preferable to avoid temporarily whitescreening a site by catching any such errors client-side before the file update is made.

This codemirror-linter for PHP currently is not doing anything with the `options` that are passed to it. If there could be a `version` passed in, then this could be used to determine whether unsupported PHP language features should be flagged as errors.

It would also be handy if there was a way to pass in a function blacklist which could pre-empt users from attempting to use unavailable functions (e.g. `proc_open` and `system`), dangerous functions (e.g. `eval` and `create_function`), or deprecated functions (e.g. `wp_list_cats()`). Use of certain functions could generate errors or warnings. This would essentially be porting implementing aspects of the [WordPress-Coding-Standards](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards) for PHP_COdeSniffer.

💡 Crazy idea: Could PHP_CodeSniffer and its sniffs as a whole be transpiled into JS and then run in the browser?

Here is the related WordPress Trac ticket: https://core.trac.wordpress.org/ticket/41873