The problem is that expect().to.be.rejected/rejectedWith (and its
negation) does not mirror how expect().to.throw (and its negation)
behave.

Same issue with assert.isRejected in relation to assert.throws.

The problem with issue chaijs#47 is that chai-as-promised somtimes treats the
final string parameter as a custom error message. We want to test that
it does not do this anymore so we check to make sure that such string is
not used as a custom error message.

- `.fulfilled`, `.not.rejected` and `.not.rejectedWith` when successful:

  * The promise they return is fulfilled with the same value as the
    promise they were testing.

- When `.not.fulfilled`, `.rejected` and `.rejectedWith` are successful:

  * The promise they return is fulfilled with the rejection
    reason.

In all cases, when they fail, the promise they return is rejected and
has for reason the assertion that failed.

The changes above make it so that the `object` flag is automatically
set when the promise returned is resolved, and thus also allows
chaining.

This fixes chaijs#113.

We now use the check-error package to get the constructor name of the
error we expect to get with `rejectedWith`. For recent versions of Chai,
this makes `rejectedWith` consistent in behavior with Chai's `throw`.

Fixes chaijs#64.

In Chai `foo.should.not.throw(Constructor, 'string')` would fail only if
the error thrown is an instance of `Constructor` **and** if its message
includes `'string'`. An instance with a different message would not
cause a failure. An instance constructed by something else than
`Constructor` would not cause a failure.

.not.rejectedWith's semantics were incompatible with the above.

This commit fixes the test to work according to the correct semantics.

chai-as-promised's `.rejectedWith` and `assert.isRejected` now mirror
how Chai's `.throws` works. Fixes issue chaijs#47.