Start splitting the block and initializer ways.

Modify TyphoonFactoryProvider to delegate the actual work of creating the
method from the protocol to TyphoonAssistedFactoryMethodCreator.
TyphoonAssistedFactoryDefinition stores subclasses of
TyphoonAssistedFactoryMethod instead of the previous array pair. The block are
now stored in TyphoonAssistedFactoryMethodBlock, where the actual work is done.

Similarly, TyphoonAssistedFactoryMethodInitializer holds the new code to
configure the mapping between the factory method and the initializer. A lot of
little classes help (TAFInjectedParameter, TAFParameterInjectedWithProperty,
TAFParameterInjectedWithArgumentIndex...). The TAFMethodInitializerCreator is
currently unimplemented.

(jasperblues/Typhoon#102)
Factory method creation from an initializer description. (WIP)

TAFMethodInitializerCreator will be split in several smaller files.
InitializerCreator creates TAFMethodClosures and stores them in a static
global NSDictionary. The closures need to live while the methods can be called
and could be a memory "leak" if the user decides to remove those methods or
entire classes from the runtime. Not very usual, so I think the solution is
"good enough".

TAFMethodClousure is where the work is done. The class describes both the
factory method and the initializer to libffi, and creates a closure that ties
them together. Many lines are taken and slightly adapted from Michael Ash
amazing MABlockClosure.

There is a small "proof of concept" test for the InitializerCreator.

Fix a copy/paste bug in the TAFMethodCreator convenience method.

TAFMethodBlockCreator and TAFMethodInitializerCreator share the code to look
for a ObjC method description.

Return the TAFMethodInitializer parameter descriptions sorted according to
their parameterIndex.

Update Pods.

TODO: lot of error checking
TODO: lot of commenting

(jasperblues/Typhoon#102)
Factory method creation from initializer description (final?)

Create separate file for TyphoonAssistedFactoryMethodClosure.

Validation of initializer and parameters during the construction of the
closure. Should catch some typing mistakes.

Use parameterIndex instead of the iteration index for filling the arguments of
the closure.

Fix a leak in typesWithEncodingString:count:. Use allocate: instead of calloc.

Use the factory method name instead of the selector name to create the keys
for the closure cache. You can have several factory methods calling the same
initializer, but only one factory method definition.

Added more complete TyphoonAssistedFactoryMethodClosureTest, testing
invocation with parameters and properties more or less in isolation.

TyphoonFactoryProviderTest duplicates the protocols before using them, so the
factory implementations are different for blocks and initializers. There is
a new test that does the same as the blocks one, but with initializers.

(jasperblues/Typhoon#102)
Conflicts:
	Pods/Pods.xcodeproj/project.pbxproj
Move class creation to their own classes.

A lot of code that used to be in TyphoonFactoryProvider is now in
TyphoonAssistedFactoryCreator and its subclasses (one for one factory block,
one for a definition block, and one for the future implicit with a result
type).

The subclasses are supposed to generate a block that returns a
TyphoonAssistedFactoryDefinition, which the super class will use in case the
class doesn't exists yet (using a block to not instantiate the definition
eagerly).

TODO: the implicit creation strategy.

(jasperblues/Typhoon#102)
Conflicts:
	Pods/Pods.xcodeproj/project.pbxproj
Split TyphoonFactoryProviderTest too.

(jasperblues/Typhoon#102)
Some fixes to compile in OS X and iOS standalone targets.

Recover libxml headers in OS X target. While including libffi as Cocoapod I
must have forgot to include this back in the OS X target (it is there in the
iOS target).

A couple of imports to avoid warnings and to correctly compile in iOS.

Marking the temporal allocations array of the closure as unused and with
precise lifetime. The unused is necessary to avoid a warning, the precise
lifetime might not be necessary, but I fear the optimizer might optimize the
variable away and break everything.

(jasperblues/Typhoon#102)
Implementation of implicit factory creator.

The method GuessFactoryMethodForProtocol moves from the OneFactory to the base
class, since the implicit creator also needs it.

The _protocol ivar moves from the @private to @protected in the Private.h
header, so the implicit creator can access it.

(jasperblues/Typhoon#102)
Factory Creator Implicit tests.

Added a bunch of bogus init methods to the PaymentImpl, to better test the
guessing of the initializer for the factory method.

(jasperblues/Typhoon#102)
Documentation, documentation, documentation (and comments).

Also some minor renaming and some declaration movement.
Use NSInvocation instead of libffi for the method closures.

Not depending on libffi and depending on Apple forwarding mechanism assure us
that they are not going to break it badly suddenly.

The code is also a lot simpler.

(jasperblues/Typhoon#102)