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

Not using autoload on purpose. Making it clear that these are internal, never meant to be reused outside of these modules. They can come & go at any time, in any release.