libclang.py weak performance spots

I was experimenting with translation unit creation flags, since `CXTranslationUnit_PrecompiledPreamble` was causing #178 and #185, and got this perf results (test source file, [boost/libs/chrono/example/io_ex1.cpp](http://svn.boost.org/svn/boost/trunk/libs/chrono/example/io_ex1.cpp)):

```
CXTranslationUnit_Incomplete | CXTranslationUnit_CacheCompletionResults | CXTranslationUnit_SkipFunctionBodies
-----------

LibClang - First parse: 0.392
LibClang - First reparse (generate PCH cache): 0.401

dura<c-x><c-u>
LibClang - Code completion time (library): 0.388
LibClang - Code matching time: 0.952
LibClang - Code formatting sorting time: 0.952
LibClang - Code formatting mapping time: 0.956
LibClang - Code completion time (library + formatting): 0.956

std::
LibClang - Code completion time (library): 0.400
LibClang - Code matching time: 0.403
LibClang - Code formatting sorting time: 0.408
LibClang - Code formatting mapping time: 0.612
LibClang - Code completion time (library + formatting): 0.612
---------

CXTranslationUnit_CacheCompletionResults
---------

LibClang - First parse: 0.646
LibClang - First reparse (generate PCH cache): 0.631

dura<c-x><c-u>
LibClang - Code completion time (library): 0.397
LibClang - Code matching time: 0.962
LibClang - Code formatting sorting time: 0.962
LibClang - Code formatting mapping time: 0.965
LibClang - Code completion time (library + formatting): 0.965

std::
LibClang - Code completion time (library): 0.382
LibClang - Code matching time: 0.392
LibClang - Code formatting sorting time: 0.397
LibClang - Code formatting mapping time: 0.593
LibClang - Code completion time (library + formatting): 0.593
---------

CXTranslationUnit_None
---------

LibClang - First parse: 0.647
LibClang - First reparse (generate PCH cache): 0.651

dura<c-x><c-u>
LibClang - Code completion time (library): 0.410
LibClang - Code matching time: 0.972
LibClang - Code formatting sorting time: 0.973
LibClang - Code formatting mapping time: 0.976
LibClang - Code completion time (library + formatting): 0.976

std::
LibClang - Code completion time (library): 0.399
LibClang - Code matching time: 0.403
LibClang - Code formatting sorting time: 0.408
LibClang - Code formatting mapping time: 0.615
LibClang - Code completion time (library + formatting): 0.615
---------
```

Take account that these timings are accumulative, so to get the time taken by a phase it should be extracted from the previous phase.

Anyway, the python formatting code is taking a lot of time at some situations you see? In these samples it seems the formatting sorting time does not interfere, but the lambda formatting code and the lambda fragment text matching code really do.

In the first case, trying to force complete from the fragment word `dura`, the time taken for the matching phase more the double the time taken by the libclang api parsing. In the namespace completion case, the problem was with the format mapping taking 1/3 of the time spent with parsing.

It seems these presented translation unit flags hadn't made a big difference between using them or not. 

I'd like to link #142 to this issue too...

LIBCLANG.PY DOES NOT DISPOSE ANYTHING!!!

It accumulates translation units and never dispose them.

**EDIT**

The following weak spots are now addressed in this pull request:

- Slow response completing word fragments with forced completion due to filtering a large amount of results using regular expressions and higher order functions, unnecessarily.
- Unrestricted memory allocation (never deallocating) for translation units. This adds a dependency on psutil python module.
- Slow response, when there's a large number of results, due to formatting and snippet-decorating all the results at once. This was a problem after a "heavy" namespace as `std::` or `boost::`.

**NOTICE**

All these performance enhancements addressed in this issue, plus patches for #186, #184 and #183 can be found at my [fork's master branch](https://github.com/oblitum/clang_complete/tree/master).

All of these, plus an updated and optimized cindex.py can be found at my [fork's cindex branch](https://github.com/oblitum/clang_complete/tree/cindex).

Also, I've created an [experimental branch](https://github.com/oblitum/clang_complete/tree/experimental) where I plan to take more freedom to improve things without willing too much to create pull requests here. I've created a blog post that mentions how I use it at [my VIM C++11 setup](http://oblita.com/blog/2012/08/30/vim-the-killer/).

**TO REMEMBER**

- `CXXPrecompiledPreamble` [is deprecated](http://clang.llvm.org/doxygen/group__CINDEX__TRANSLATION__UNIT.html#ggab1e4965c1ebe8e41d71e90203a723fe9a7c55905793254bd43d9f46964b1883fa).
- `CacheCompletionResults` currently contains [unexpected side effects](https://github.com/Rip-Rip/clang_complete/pull/187#issuecomment-7844527).
- Currently, the single requirement to adopt an updated cindex.py from clang's trunk is to use `PARSE_PRECOMPILED_PREAMBLE` instead of `PrecompiledPreamble` at libclang.py (and obviously do not forget the new enumerations.py).