Asynchronous, non-blocking matching

From https://github.com/kien/ctrlp.vim/pull/542:

**Note:** This is a PR from master..master and looks very unclean.

> Hello,
> 
> I've been playing around with making the matching phase of ctrlp asyncrhonous, since that was the biggest bottleneck when working on big projects.
> 
> I've reached the phase where things are actually looking good and I would like more eyes on the changes, and comments on whether this would be a good candidate for merging.
> 
> There are basically two sets of changes:
> 1. The core of ctrlp is changed so that matching functions call a public #process function when they are done with the result, rather than returning it. This requires the current match plugin interface to be broken, but also allows plugins like cmatcher to execute their matching function in a separate/process thread, and then give the result to ctrlp for processing.
> 2. A public function #forcecursorhold is introduced to force a cursorhold autocommand. This is in the core since only that has the necessary information to produce a cursorhold event without actually changing anything. Of course, matcher functions can also use the remote expression interface of vim for truly asynchronous matching.
> 3. The match plugin interface now allows plugins to define whether they want ctrlp to always force an update, via the 'force_update' key. This is necessary when using the cursorhold event for asynchronous work.
> 4. Finally, a matcher written in python is introduced, and used when vim has python support and lazy updating is active. The python matcher does the matching and sorting in a separate thread, and uses the cursorhold event to check if the thread has finished its work. The matcher is a drop-in replacement to the viml matcher and supports everything, including regexp matching using the vim regexp syntax