add chained expectation descriptions to the default descriptions of custom matchers with fluent interfaces

this fixes #532
> Either way they'll have to know about it if they have a mix of matchers.

I don't think this is true.  They'll only have to know about it under the following conditions:

* They are using DSL defined custom matchers that are defined both in their project and in 3rd party gems.
* These custom matchers use the `chain` part of the DSL.
* These custom matchers override `description` and use `super()`.

IMO, very few projects are going to meet those conditions.  For the few that do, they can customize particular matchers to work opposite the global config option by overriding `description` (so we're not limiting their ability to do this by not offering `include_chained_clauses`).

For the common case, it's going to be painful to have to add `include_chained_clauses` -- particularly when I would consider this an oversite on our part...given that we generate a useful `description` and offer `chain`, we should have included the chain clauses all along.  It's a crappy user experience to force users to correct our mistake by manually calling a method on each matcher to make the matcher behave as it should have behaved all along.  Compare that to the experience users will get when they start a new project, get the config option automatically enabled by the generated `spec_helper`, and get the benefit of this change without ever having to think about it.

> I've come across several cases of clients using private gems to share such things and they're more likely to be built using the DSL in that case

I tend to think of "3rd party gems" as referring to gems built by some 3rd party -- that is, not by us (the RSpec team) or by a coworker.  For these sorts of private gems, the users control the source and it seems like much less of an issue to change the code to deal with this (or they can just keep the config option off).