Small confusion around config.action_view.cache_template_loading

Changes introduced by "this patch": http://github.com/rails/rails/co... create a small bit of confusion because of the overlap with @config.cache_classes@:

config.cache_classes = true
config.action_view.cache_template_loading = true
# - no STAT call each request, no reloading templates
# - expected behaviour
# - default for prod env

config.cache_classes = false
config.action_view.cache_template_loading = false
# - STATs every request, full view path check every request
# - expected behaviour
# - default for dev env

config.cache_classes = true
config.action_view.cache_template_loading = false
# - STATs every request, but no rechecking process_view_paths
#       i.e. won't discover new files, but will update existing ones
# - pretty much expected behaviour IMO
# - probably quite a rare setup

config.cache_classes = false
config.action_view.cache_template_loading = true
# - no STATs, HOWEVER, process_view_paths gets executed every request...
#     i.e. (Dir.glob("#{dir}/**/*/**") | Dir.glob("#{dir}/**")).each do |file| ...
#     i.e. STAT calls are really not going to be your main problem
# - somewhat confusing because reloading classes doesn't really imply rechecking views
# - but most people won't think this far...
# - also probably quite rare

It's not a big deal, but it seems to be a fairly unnecessary source of potential confusion.

Proposed solution:

• Rename config.cache_classes to something more all-encompassing like config.reload_app_each_request.
• Get rid of config.cache_template_loading entirely and have ActionView::TemplateHandlers::Compilable#compile_template? check config.reload_app_each_request directly instead.

I don't think anyone actually needs this level of granularity. "reload_app_each_request" is blunt, but descriptive and easy to reason about.