Resolve duplication between property and key assertions

[alexjeffburke]

In Unexpected core we have a series of assertions for properties/keys of objects that are almost identical. At a high level, the main difference between the "properties" and "keys" variants is whether they agree with our undefined ignoring semantics and/or accept vargs or an array of strings.

TL;DR I believe we should deprecate undesirable variants now for removal in Unexpected 12. I have marked those those I consider candidates below.

Based on earlier discussion (https://gitter.im/unexpectedjs/unexpected?at=5de56d5b9319bb5190cefcf0), the "to have keys" is the only remaining assertions in core that does not adhere to our ignoring undefined rules. For this reason I worked from the angle that these should be considered for removal.

Suggested deprecations The following assertions all exist in cleaner variants.

• [ ] "to [not] have keys <string+>" docs
  • does not agree with our standard handling of undefined
  • a large chunk of mostly duplicated code
  • uses an oddly placed "not"

  • removing this means also removing the only flag (see next item)

• [ ] "to [only] have keys <array>" docs
  • "only" flag represents most of the assertion
  • has a perfectly good alternative in "to have only properties <array>"
  • suggest removing this flag but no others
• [ ] "[not] to have keys <string+>" docs
  • cannot be made to support symbols or numeric keys
  • we have generally moved away from vararg keys
  • has a perfectly good alternative in "to have properties <array>"
• [ ] "to [not] [only] have key <string>" docs
  • uses an oddly placed "not" - suggest removing this flag but no others

Noted during research The following assertions are duplicated, but their implementations are small and thus I accept that the churn might not be worthwhile.

• "to have key " docs
  • almost identical to "to have property <string>"
• "to have keys " docs
  • almost identical to "to have properties <array>"