refactor how we represent and store checkers using python as a demo

Add 2 classes: SyntasticChecker and SyntasticRegistry.

SyntasticChecker represents a checker. It holds funcrefs to the checker
func, the highlight regex func and a new `isAvailable()` func (that
essentially just checks if the checker exe is installed)

SyntasticRegistry is responsible for:
* loading checkers
* storing checkers
* fetching the checkers to use according to availability and the users
  settings

Motivation/benefits:
* in the current system only one checker can be loaded per filetype
* syntax checkers cant be "chained" together
* the system is hard to add features to since fundamental concepts like
  syntax checkers and location lists arent represented explicitly

Things left to do:
* add a call to g:SyntasticRegistry.CreateAndRegisterChecker() to all
  checkers
* add an `isAvailable` function to all checkers
* move all checkers into `syntax_checkers/filetype/checkername.vim` -
  g:SyntasticRegistry assumes this layout, and its a good idea anyway
  for consistency and it makes it easier for users to add their own
  checkers

Things to do after all of the above:
* add a LocationList class and move all the filtering functions onto it
* possibly add an Error class that wraps up each item in a loc list

Random notes:
* with the new system you can select the checkers to use with e.g.
    `let g:syntastic_python_checkers=['flake8', 'pylint']`
  This will try flake8 first, and if no errors are detected it will move
  onto pylint.
refactor all the syntax checkers to use the new API and dir layout
fix a couple of bugs with ruby checkers
update how checkers are chosen

* add a system for setting default checkers
* return the first check we find, unless told to chain checkers together
  by default settings, or user settings
bugfix for eruby checker
Merge branch 'refactor_checker_structure' into merge-with-refactor

Conflicts:
	syntax_checkers/cpp/gpp.vim
	syntax_checkers/objc/gcc.vim