Finished SessionsController rework.

Now uses new `(action)SessionResultHandler` command-pattern classes to
do (usually) result-based post-DSO processing at the implementation
level (redirecting, assigning controller instance variables, etc.) Not
perfect, but the fugliness is hidden at this level.

Note that the `SessionsController` *spec* is still nearly 150 lines
long, even though the controller itself is three two-line-each methods
that make use of nicely decoupled classes. So why leave the controller
spec as it was for a single megalithic implementation? It's a Good
Thing to leave it that way *during the transition*, so that you're
using a (relatively) constant spec to verify that your refactoring
didn't blow anything to smithereens. A justifiable future activity,
however, would be to decouple the existing *spec* to match the
now-decoupled *code*; have, say, a nice straightforward spec for
`CreateSessionResultHandler` that verifies *just that*, leaving the
controller spec to merely prove that each supported action can be
called along its most usual case, leaving the details for the specs for
the classes that *sweat* the details.

RSpec: 917 examples, 0 failures, 85 pending
RuboCop: 236 files inspected, no offenses detected