chore: use --update-if-exists when creating broker

[blgm]

Previously we would always try and create the broker, and if that failed (for any reason) then attempt to update it. This resulted in output that sometimes confused users.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/187056373

The labels on this github issue will be updated when the story is started.

[fnaranjo-vmw]

This looks great.
I also saw you contributed the implementation of this flag:
cloudfoundry/cli#2402

Do we need to keep anything in mind?
Do we need to ensure anything in our tiles?
What are the implications of --space-scoped being ignored (as you describe in the PR for implementing this functionality)?:
https://github.com/cloudfoundry/cli/pull/2402/files#diff-d7f338e1080712cfb134a0de446ec4cfc0878968f3dd517dbb841cdc9cb03ef8R18

Is it relevant that our script was using --space-scoped? And the fact that we haven't removed it but now will get ignored?

After reading the implementation PR and CloudFoundry docs I believe I understand that:
If the service-broker already exists but it was not created with --space-scoped flag the update command will not:

• Try to convert the service-broker into a --space-scoped one
• Fail or warn the user about this inconsistency

Is it possible to query whether a service-broker is space scoped or not?
If the service-broker exists already. Wouldn't be more sensible to either:

• check that any passed flag if that flag actually describes the existing service-broker otherwise fail
• continue using the pipe approach which at least offers a clear separation of flags

I acknowledge this inconsistency was not created by your PR.
I see that update-service-broker command doesn't accept the --service-scoped command.
I guess that means that once a service-broker gets created it is impossible to modify it with a single command to become a --space-scoped one. I guess we should have to live with it, although it seems confusing to me.