Add project metadata to the gemspec

`RSpec::Matchers::BuiltIn::All` keeps track of which objects failed at
which index of the actual value in a `@failed_objects` hash. The matcher
considers a match successful if `@failed_objects` is empty. When the
matcher is composed inside another matcher, the matcher gets cloned
before matching against each item in the actual collection.  The
`@failed_objects` hash doesn't itself get cloned, resulting in each
cloned matcher having a reference to the same hash. This means that once
a matcher (or one of its clones) fails – populating `@failed_objects` –,
each of its clones will fail matching regardless of whether it matched
or not, as each clone's `@failed_objects` reference is not empty. This
leads to behavior like the following, where we see the first failure
(expecting `false` to be `true`) repeated twice.

```
expect([[true], [false]]).to all(all(be(false)))

RSpec::Expectations::ExpectationNotMetError: expected [[true], [false]] to all all equal false

   object at index 0 failed to match:
      expected [true] to all equal false

         object at index 0 failed to match:
            expected false
                 got true

   object at index 1 failed to match:
      expected [false] to all equal false

         object at index 0 failed to match:
            expected false
                 got true
```

The solution here is to clone the `@failed_objects` hash when the
matcher itself is cloned. So long as the matcher itself is cloned
immediately after construction (while `@failed_objects` is empty)
– which is what actually happens – we avoid this bug.

Alternative solutions include:

* calling `@failed_objects.clear` at the start of each `matches?` call
* lazily defining `@failed_objects` (i.e. outside of the constructor) so
  that when the matcher is cloned, `@failed_objects` isn't defined yet
  and so cannot have shared references to it

However, the pattern already exists where, when the matcher is cloned,
its 'submatcher' (composed matcher) is cloned. Cloning `@failed_objects`
at this time follows the same pattern.

#1034 introduced a hash comparison in addition to an equality check. The change compared not only the objects themselves, but also their hashes which broke for poorly behaving Ruby objects.

E.g. (using `rspec-rails`):

    it { expect { 'noop' }.not_to change { country.reload.cities } }

By caching the hash immediately after the block has run we should be able to work around such examples.

BasicObject doesn't define certain Ruby methods matchers rely on, in this case issue an ArgumentError to better explain the error.

* Added kindly failure message for #1105
* raise ArgumentError instead of printing special failure message
* added examples for following cases
- actual object does not respond to #kind_of? method
- actual object does not respond to #is_a? method
* removed #error_message method and give the error message inline