Change @env_config to @app_env_config

Moral of the story: One must be careful about lazily initializing
instance variables when subclassing.

I would like to draw your attention to https://github.com/rails/rails/issues/4652 where
the reader will see that there appears to be some kind of initialization issue
in rails.

The source of this issue is that:
1) Engine#env_config contains "@env_config ||= ..."
2) Application#env_config contains "@env_config ||= ..."
3) Threads are in the picture
4) Thread A calls Application#env_config, which super's to Engine#env_config
5) After Engine#env_config returns but before Application#env_config sets @env_config again, Thread B begins running
6) Thread B calls Application#env_config
7) Thread B finds @env_config to contain a value (the one set by Engine#env_config) and returns it
8) Thread B blows up because key set by Application#env_config are there.
9) People report bugs with puma, thin, rainbows, webrick, etc
10) Evan becomes tired of seeing these bugs
11) Evan pours himself a stiff drink, puts on Top Gear(tm), and begins debugging
12) Evan finds the source of the bug
13) Evan authors a PR
14) RIGHT NOW.

The bug is fixed by simply using a different ivar name in the methods.
Alternately, Engine#env_config could just return a new Hash each time, not memoizing into @env_config.

I bid you adieu.
Merge pull request #9789 from puma/3-2-stable

Change @env_config to @app_env_config
Backport #9347 to rails 3.2
Merge pull request #9804 from samsonasu/backport_number_to_human_fixes

Backport #9347 to rails 3.2
Reset postgreSQL search path in db:test:clone_structure.
This patch resets the postgres search path in the structure.sql after
the structure is dumped in order to find schema_migrations table when
multiples schemas are used.

Fixes #945
Merge pull request #9796 from dembskoi/clone_structure

Reset postgreSQL search path in db:test:clone_structure.
Be consistent with quotes in smtp example guide [ci skip]
fixes #9812