Quick fix for uncaught 409 on slug conflict.

[Fil]

This error is raised when you have opted in to create a new project, but asked for an existing slug.

There are two slightly different recommendations in the two issues that discuss this problem:

1. validate the slug uniqueness early (If a slug is already taken, show a better error, and prompt for a new slug #713)
2. allow to reuse a slug (409 error should display a better error message #909)

This PR is a simple cosmetic display of the error; (note: I think it's fair in this case to terminate the session, since in this case we opted-in to create a new project, and not to push into an existing project—which is a way to reuse a slug; unless, there is a case where the slug is "taken" by a project you can't see?)

This does not change the workflow, but only fixes the displayed message to make it more palatable. I reckon that my code is ugly ("error as any", yuck), and maybe what we want is a clean "api error with messages" instead, like we have just above these lines. In that case there is a bit of work to do on the platform before we would fix this in the client?

I'm putting up this "ugly" solution as a PR, but feel free to reject it in favor of a nicer approach. The workflow with this PR is:

◇  Which project do you want to use?
│  Create a new project
│
◇  What slug do you want to use?
│  already-taken
│
◇  Who is allowed to access your project?
│  Public
│
●  You built this project 18 minutes ago.
│
◇  Would you like to build again before deploying?
│  No, deploy as is
│
◇  What changed in this deploy?
│  Enter a deploy message (optional)
│
■  Could not create project: conflicting slug.    ☜ this instead of an uncaught error
│
└  Deploy canceled

closes #909
closes #713

[mythmon]

The type safe version of this would be something like

if (isErrorMessage(error) && error.statusCode === 409 ...

This is probably fine as is.

[mythmon]

It would be nice to prompt the user in a loop instead of throwing an error, but that's a bit bigger change than I think you want to tackle in this PR. Or maybe even clack can do async validation and we can do it that way?