Ensure metadata cache is not ArrayCache in production

This PR adds a new check to Configuration::ensureProductionSettings(). It ensures that the metadata cache does not use ArrayCache in production.

The ArrayCache forgets everything at the end of each request, while the other bundled cache engines (Memcache, MongoDB, FileCache etc.) may keep entries for much longer. The metadata only changes when the source files are changed, so in production the metadata cache only needs to be cleared when new files are deployed, just like the generation of proxy classes.

It is possible to specify/modify metadata dynamically at runtime e.g. using the loadClassMetadata event so that the metadata changes without any changes to the source files, but I assume this is not a supported use-case (at least not without clearing the metadata cache manually). Agree?

The ArrayCache is the default cache engine added by e.g. [Doctrine Bundle](https://github.com/doctrine/DoctrineBundle) (for Symfony) and [Doctrine ORM Service Provider](https://github.com/dflydev/dflydev-doctrine-orm-service-provider/) (for Silex), so most developers are probably not aware of it. However, accessing the metadata at run-time has a significant performance impact (for some anecdotal evidence, see https://github.com/doctrine/common/pull/319#issuecomment-60945429), so a warning in ensureProductionSettings() is relevant.

The PR also fixes the units for ensureProductionSettings() that were previously not being run due to a missing "test" prefix on the ConfigurationTest::ensureProductionSettings method name.
They are already exposed, but this is not very clear. In fact, this weekend I was working on a patch to clarify this, https://github.com/c960657/doctrine2/commit/018e54389f83a0022dcefb07b2694f0d184cc354. I will submit a separate PR later. However, I expanded the testEnsureProductionSettingsAutoGenerateProxyClasses() test into three different tests, one for each auto-generation style.

For now I have kept the existing behaviour that even all other values than AUTOGENERATE_NEVER are not considered suitalbe for production, though I guess you could argue that AUTOGENERATE_FILE_NOT_EXIST is also acceptable.