Support defining default failure chains in the env

When constructing chains, it's then possible to
build on top of those default failure chains.

An example:

env = Substation::Environment.build do
  register :sanitize, Substation::Processor::Evaluator::Data do
    wrap Error::SanitizationError
  end
end

action = env.chain do
  sanitize Some::Sanitizer do
    wrap Views::MalformedInput
  end
end

If invoking action produces a sanitization error,
the sanitizer output will first get wrapped inside
Error::SanitizationError which in turn gets wrapped
inside Views::MalformedInput.
Sync devtools
Rename protected Chain#{handlers => processors}
Don't force Processor implementations to be immutable
Refactor Chain#call spec to work with processors
Let processors decide wether to halt the chain
Add missing contexts to Chain#call specs

While the previous specs for this method were
already mutation covered, the new contexts make
sure that all different chain processor types
(incoming, pivot, outgoing) actually halt or
continue a chain invocation properly.

The previous specs for example didn't fail with
the following monkeypatch:

module Substation
  module Processor
    module Pivot
      def success?(response)
        true
      end
    end
  end
end
[ci skip] Clarify processors vs. handlers in the README
[ci skip] Fix available processor methods in the README
Move processor support logic to Processor modules
[ci skip] Fix class docs for Chain
Introduce EMPTY_ARRAY and use it where appropriate
[ci skip] Fix more class docs for Chain
Sync devtools
Nuke leftover visibility modifier
Sync devtools
Simplify and power up failure chain (re)definition
[ci skip] Update README to reflect latest changes
Don't provide a default Processor#initialize

Also adds a spec that makes sure that Fallible
processors respond_to?(:name)
Merge pull request #6 from snusnu/failure-chains

Support easy (re)definition of failure chains