Change MapBuilder architecture to build TableMap on-demand

[hans]

A rather runtime-intensive part of current Propel initialization is the initialization of the MapBuilder classes.

This can be done in a more on-demand way, by registering the table-building MapBuilder classes with the DatabaseMap and only actually building the TableMap objects when needed.

[hans]

Replacement DatabaseMap file

[hans]

We probably also can simplify the static code at the end of the generated peers to be something more like this:

<?php

// static code to register the map builder for this table with the main Propel class  
try {
  Propel::getDatabaseMap(AuthorPeer::DATABASE_NAME)->addTableBuilder(AuthorPeer::TABLE_NAME, AuthorPeer::getMapBuilder());
} catch (Exception $e) {
  Propel::log('Could not initialize Peer: ' . $e->getMessage(), Propel::LOG_ERR);
}

[hans]

Added implementation in large (PDO-related) changeset:372

[hans]

IMPORTANT: because the static code is now in the extended stub classes, these must be manually deleted and re-generated.

The reason this code had to move to the stub class is that the Peer constants and the getMapBuilder() method require that the stub Peer class be loaded. However, since that code was at te bottom of the Base Peer class it couldn't reference anything in the Peer. It's tricky to explain, but there wasn't any clean way to keep that static code in the generated Base Peer class.

A side-effect of moving the static code to the stub classes is that we can use Peer constants and methods inside the map builder classes.

[hans]

Wrapped up this ticket in changeset:423.

I reverted the requirement that the static map builder registration be in the stub class. That was a bad idea, as it made it much more tedious to rename classes.

[hans]

Added preliminary version of these changes to 1.3 branch in changeset:444