Service Plans compare by unique_id OR plan name.

Implemented Plan.collection_subtraction and
Plan.collection_intersection, because this OR "equality" breaks ruby
set math comparison, which relies on #hash and #eql?

[#61090514]

Signed-off-by: Zach Robinson <zrobinson@pivotallabs.com>
Stop overriding eql? and hash

Use the same? comparison everywhere.
Refactor plan tests.

Signed-off-by: Jimmy Da <jda@pivotallabs.com>
Refactor plan advertisement.

Signed-off-by: Jimmy Da <jda@pivotallabs.com>
Build service lists using tuple fallback

When the broker is creating a changeset by comparing its own catalog
with the catalog from CC, the broker will try to find matching services
using the unique_id first, and if no matching services are found, the
broker will try again using the label-version-provider tuple. Because of
this change, we can no longer use the set operations enabled by overriding
eql and hash, and instead build the different sets using our new
matching rules.

[#61090514]

Signed-off-by: Zach Robinson <zrobinson@pivotallabs.com>
Refactor the way we determine which plans to add or update

Signed-off-by: Zach Robinson <zrobinson@pivotallabs.com>
Service can be provisioned with matching plan name.

On provision, broker can verify plan exists if no matching
unique_id is found by falling back to name compare.

[#61090514]

Signed-off-by: Jimmy Da <jda@pivotallabs.com>
Bump version.

Signed-off-by: Jimmy Da <jda@pivotallabs.com>
Provision should now fail when both unique_id and plan name are unknown