Service bindings with invalid names return the same error as service bindings that already exist

Issue

Service bindings with an invalid name return same error code as bindings that already exist

Context

Trying to create a binding with a custom (invalid) name such as A binding name with spaces causes CC to return:

{
  "code": 90003,
  "description": "The binding name is invalid. Valid characters are alphanumeric, underscore, and dash.",
  "error_code": "CF-ServiceBindingAppServiceTaken"
}

but this is the same error code as when a binding already exists:

{
  "code": 90003,
  "description": "The app is already bound to the service. The binding name is invalid. App binding names must be unique. The app already has a binding with name 'a-valid-binding-name'.",
  "error_code": "CF-ServiceBindingAppServiceTaken"
}

The CF CLI then assumes that code 90003 corresponds to the second case where the app is already bound to this service see here which is a bit of a misleading error message.

Steps to Reproduce

• Create a service - cf cups a-service -p '{"foo": "bar"}'
• Create an app cf create-app an-app
• Try to bind the app with a bad name - cf bind-service an-app a-service --binding-name "A binding name with spaces"

Expected result

The CLI tells me that this name is invalid

Current result

The CLI thinks that the error is due to the service binding already existing

Possible Fix

Use a different error code for the case of an invalid name vs. an already used name or use a different HTTP code such as 409 Conflict for the case where it already exists

Start with the bind-service behavior described in the reproduction steps and review cf/commands/service/bind_service.go around lines 128-136. Reproduce the invalid binding-name case and compare it with an existing binding. Done means the CLI reports an invalid name distinctly from an already-existing service binding, using the API behavior selected for the fix.