[WIP] Fix more than one record generator initialisation on same php process

[alquerci]

What provides this patch?

• Be able to use record generator for more than one connection the main usage is for a replica (e.g. master/slave, sfDoctrineMasterSlavePlugin).

How the bug is going to be patched?

• Add test to avoid BC breaks when the class record can be autoloaded
• Add test for table serialization with I18n behavior and its record filter
• Add record post setUp event. This is required to define filters that depend on a specific relationship (e.g. sfDoctrineRecordI18nFilter)
• Fix table serialization for record filters.

Side note

• The sfDoctrinePlugin need to be fixed in consequences.
• The current directory to run tests must be fixed to tests.

Tests

• Before TravisCI Build #107
• Add test TravisCI Build #112
• Impl fix TravisCI Build #113
• Update to table cache TravisCI Build alquerci#10
• Impl table cache for record generator TravisCI Build alquerci#11

Adds 6 assertions with 0 new failures.

Todo

• [ ] Implement the proper patch for behaviours that remove fields from the own table

cc @j0k3r @GromNaN

[alquerci]

It seems to work on test cases but in a real usage as the generated class is not taken from cache too. All behaviours that moves columns like as I18n does not works.

Such issue should be caught by tests but it seems there is something missing on the test execution.

[alquerci]

Indeed with the fix on the test case the bug appears.

I push a quick patch for the I18n behaviour but serialized data should be frozen before setup.

[alquerci]

A possible patch is to store all informations about removed fields somewhere and store on serialization data.

A better patch will be to cache generated record tables as well.

@j0k3r @GromNaN what is your point of view about the issue when a column is removed by a behaviour?