Refactor Result object handling

First, SuccessfulResult and ErrorResult are back. This will let us do
stuff like the following in controllers:

    def create
      @user = AuthenticatingUser.new.set(user_params_for_create)
      case result = repository.insert(@user)
      when Norm::SuccessResult
        session[:user_id] = @user.id
        redirect_to root_path, :notice => 'Account created!'
      when Norm::ErrorResult
        add_errors(@user, result.value)
        flash.now[:alert] = 'Problem creating account!'
        render :new
      end
    end

second, two factory methods on the Result class were added:

Result.for is essentially a replacement for Result.new. If given a
Result object, it returns the object. Otherwise, it returns a
SuccessResult value object with the object as its value.

Building on this, Result.capture(*error_classes) will let you capture an
arbitrary set of errors in an ErrorResult object if the block it's
provided raises an error. If the block exits cleanly, its return value
will be returned in a SuccessResult object, instead.

This is far more reusable (and almost self-documenting) as compared to
the less-discoverable keyword argument on atomically/atomically_on.

It opens up the possibility that maybe we might prefer to allow a
controller (or another object) to determine if they want to handle
constraint errors instead of making the Repository do it, as well.