Fixed invalid generation of INDEX statements in Table::addExtraIndices() [only MySQL].

If a table has a foreign key on a column of another table that is dynamically created (through a behavior) then Table::addExtraIndices() creates a invalid INDEX since it can not find the referenced (not yet created) column. Because a new column of a behavior can be created later than the addExtraIndices() call of a referencing table, the addExtraIndices should always overwrite his indices. Old behavior was that addExtraIndices always creates a new index if the columns of the foreign key has changed (and this is the case if the engine finds the referenced column during a later call).

Example:

    INDEX `test_item_category_relation_FI_1` (`item_id`, ``),
    INDEX `test_item_category_relation_FI_2` (`item_category_id`, ``),
    INDEX `test_item_category_relation_FI_1` (`item_id`, `workspace_id`),
    INDEX `test_item_category_relation_FI_2` (`item_category_id`, `workspace_id`),

`workspace_id` is a column created through a propel behavior.

This commit
fixes
 - the scenario above by adding Table::hasIndex and Table::removeIndex() und use those methods in Table::addExtraIndices().
 - two typos.
 adds
  - a new test in generator/model/TableTest that replicates the bug.
Very small performance increment by breaking the loop if we found the index to be removed.
Adjusted coding style.
Merge pull request #561 from MArcJ/fk-index-bug

Fixed invalid generation of INDEX statements in Table::addExtraIndices()...