Remove TranslatableSetting (will return in v7.0.0)

RATIONALE:

There are tons of things done only for backwards compatibility.
Specifically, it’s the __str__ and __unicode__ methods returning
a sane value (so it’s a drop-in replacement in templates).  Then there
are all those dunder magic methods, which are done to fix things like
indexes_title + indexes_pages.  A much saner solution would be to
elliminate all the uses of “bare” variables here and call()† the
settings, returning a string instead of a TranslatableSetting object,
making it faster and nicer.

Even though we can modify our codebase and our themes, all the
third-party things (including themes and plugins) would break.  This
is not nice.  And although __str__/__unicode__ are likely to stay in
(which will make themes mostly compatible unless they are Mako themes
and are doing something crazy, like the aforementioned string
concatenation).

But, you might be saying “it will break in v7.0.0 then!”.  The answer
to that concern is easy: That version is DESIGNED to break backwards
compatibility.  We are free to break everything, unlike this minor
release of v6.4.0.  And we could even get rid of __str__/__unicode__,
by forcing everyone to call()† us, producing the standard ugly
__repr__-esque thing of `<….TranslatableSetting object at 0x…>`.

The “fixed” implementation should be back to master in early March.

† By that, I mean execute the __call__ method of the settings.  This
  is a magic method, executed by calling an instance, that is:

      A = TS('something')
      print(A())

  This matches the usage of post.title().  The instantiation happens
  internally, so we will just say “post.title and blog_title work
  the same way” to users — and we won’t lie.

cc #1057, #851

Signed-off-by: Chris “Kwpolska” Warrick <kwpolska@gmail.com>