The controller can set the response format as 'JSON' before the renderer code be
evaluated, so we must replace it when necessary.

Fixes #15081

When requesting a controller with the following code with a unknown format:

    def my_action
      respond_to do |format|
        format.json { head :ok }
        format.any { render text: 'Default response' }
      end
    end

we should render the default response instead of raising ActionController::UnknownFormat

Fixes #14462

Conflicts:
	actionpack/CHANGELOG.md
	actionpack/test/controller/mime/respond_with_test.rb

Conflicts:
	actionpack/CHANGELOG.md

No variant should also be picked up by variant.any if variant.none is not defined (just like any other variant)

Allow setting `request.variant` as an array - an order in which they will be
rendered.

For example:

  request.variant = [:tablet, :phone]

  respond_to do |format|
    format.html.none
    format.html.phone # this gets rendered
  end

Like `format.any`, you can do the same with variants.

It works for both inline:

    respond_to do |format|
      format.html.any   { render text: "any"   }
      format.html.phone { render text: "phone" }
    end

and block syntax:

    respond_to do |format|
      format.html do |variant|
        variant.any(:tablet, :phablet){ render text: "any" }
        variant.phone { render text: "phone" }
      end
    end

In most cases, when setting variant specific code, you're not sharing any code
within format.

Inline syntax can vastly simplify defining variants in those situations:

  respond_to do |format|
    format.js { render "trash" }
    format.html do |variant|
      variant.phone { redirect_to progress_path }
      variant.none  { render "trash" }
    end
  end

Becomes:

  respond_to do |format|
    format.js         { render "trash" }
    format.html.phone { redirect_to progress_path }
    format.html.none  { render "trash" }
  end

This reverts commit 18616114, reversing
changes made to cad9eb17.

In most cases, when setting variant specific code, you're not sharing any code
within format.

Inline syntax can vastly simplify defining variants in those sitiations:

  respond_to do |format|
    format.js { render "trash" }
    format.html do |variant|
      variant.phone { redirect_to progress_path }
      variant.none  { render "trash" }
    end
  end
`
Becomes:

  respond_to do |format|
    format.js         { render "trash" }
    format.html.phone { redirect_to progress_path }
    format.html.none  { render "trash" }
  end

By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:

  app/views/projects/show.html.erb
  app/views/projects/show.html+tablet.erb
  app/views/projects/show.html+phone.erb

If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.

In the controller, we can also tailer to the variants with this syntax:

  class ProjectsController < ActionController::Base
    def show
      respond_to do |format|
        format.html do |html|
          @stars = @project.stars

          html.tablet { @notifications = @project.notifications }
          html.phone  { @chat_heads    = @project.chat_heads }
        end

        format.js
        format.atom
      end
    end
  end

The variant itself is nil by default, but can be set in before filters, like
so:

  class ApplicationController < ActionController::Base
    before_action do
      if request.user_agent =~ /iPad/
        request.variant = :tablet
      end
    end
  end

This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.

This fixes an issue where the respond_with worked directly with the given
options hash, so that if a user relied on it after calling respond_with,
the hash wouldn't be the same.

Fixes #12029

This interface should be use when implementing renderers.

Currently if a user calls #respond_with(csvable), but has not csv
renderer available, Responder will just run through the default render
behavior twice, raising ActionView::MissingTemplate both times.

This changes ActionController::Metal::Responder#api_behavior to check
in advance whether there is a renderer available, and raise
ActionController::MissingRenderer if not.