Reference string constants rather than repeatedly allocating the same string

This is driven by @fxn's work on `StringPool` to deduplicate commonly used strings: https://github.com/rails/rails/compare/fxn/string-pools

The cases covered here are a partial treatment, guided by object allocation profiling to reveal hotspots in common Basecamp actions.

* When in doubt, don't. This technique is ugly. Profile first and justify.
* Keep string constants close to their usage. No long lists of random strings. Keep it crystal clear what relies on the strings and why.
* Only share toplevel string constants for very commonly reused strings, like the empty string, underscore, spaces, etc.
* Don't reference toplevel string constants between libraries. Reference constants within the same library. Duplicated constants are OK.

Work in progress:

* [ ] Merge @fxn's work: https://github.com/rails/rails/compare/fxn/string-pools
* [ ] Merge @tenderlove's work: https://github.com/rails/rails/pull/12879/files
* [x] Eliminate constants that are used as string keys in Hash literals, which are automatically deduped in Ruby 2.1
* [ ] Eliminate constants that are used as string keys in Hash lookup and assignment, which are automatically deduped in Ruby 2.2

These are all used as constant keys to the `env` hash, so we can remove them all and still get dedupe win on Ruby 2.2.