Add a fast way to look at an NSString
Monstrous commit from hell

I managed to rm -rf my .git and lost all my commit logs, so I'll try to
explain what those 3 days of work are doing.

XVimWindow
**********

First, I've beeen simplifying the hooking of XVimWindow to be a bit
cleaner, use one single Associated Object, let the window own its command
line, and things like that.

XVimTextStoring
***************

I also started a clean XVimTextStoring protocol, and ported the
NSTextStorage VimOperations category to implement it. The protocol is a
bit overkill, but it can help us detect at runtime whether our code was
hooked properly by checking whether the NSTextStorage instances we're
looking at are hooked properly.

I also moved the specific DVT* optimizations of that implement the default
NSTextStorage+VimOperations in a more efficient way to a separate file,
and if you want to support an alternate NSTextStorage subclass, then
that's how you should do it, it keeps code separated.

In the category, I've started migrating many of the functions that were in
the VimOperation category, with a unified naming and conventions,
vocabulary. Typically Position is now reserved for XVimPosition, Index for
index in the xvim_string and so forth.

All the functions there are xvim_ prefixed to avoid accidental clashes at
runtime, and for debugging purposes: it's way simpler if we see xvim_ in
the selector name to understand it's ours.

A big change is that I've been using more Cocoa code to detect where line
start and end, and I've declared the war on isWhitespace, isNewline and so
forth. This will end up having a more consistent notion of linenumbers
than the default XCode UI. It also means that we probably will end up
supporting CR/LF/CRLF files more transparently.

XVimBuffer
**********

I've added an empty class, and a new XCode group about "Buffer". The idea
is to really have a Buffer object like in vim, that represents the file
content. The textStorage is its storage, but it will have references to
the undo manager, and anything related.

The NSTextView is pretty much the same notion as a window in vim, IOW you
can have several "views" on that file, and remembering anything related to
the NSTextView is bogus, because the view can change its storage, its
whole stack. In vim, even the visual selection isn't per window but per
view. Very little is per window, but for the cursor position.

So the plan is to move most of the code away from the NSTextView category
into the NSTextStorage one. We may want to have several of them for
readability purposes obviously.

Dropped code
************

Some dead code has been stripped.
And several selectors like -nextPositionFrom:matchingColumn:returnNotFound:
have been removed, because they can be easily reimplemented with the new
ones with a better semantics. Typically for -nextPositionFrom:..., the
fact that the column should be after the column of the index argument was
never used by any caller (they all went to the beginning of the line first
to avoid that artifact), and it was actually hard to maintain.

So simpler alternatives have been chosen in a lot of places.