Bolt publish fails because npm can give wrong information quite often

Through no fault of this project, `bolt publish` can still fail when npm has data replication issues.

We are now seeing this issue tens of times a day in the atlaskit-mk-2 repo.

**Scenario**

* A package is published (e.g pkg-a@1.0.1)
* Later than day `bolt publish` is run to release any unrelased packages.
* bolt runs `npm info` for each package in the repo to find which are ahead of npm
* npm says that the latest version of `pkg-a` is `1.0.0`
* local version is 1.0.1 so bolt marks it as ready to release
* bolt attempts to publish `pkg-a@1.0.1`
* npm returns a 403 as you cannot published over an already published version.

**Suggested fixes**

1. We could look for another source of truth for which versions have been deployed. Unfortunately:

* `npm info` can be wrong
* `yarn info` can be wrong
* unpkg *can* be wrong (but is correct more often than `npm info`)

🚫So this likely wouldn't solve the problem (unless there is a better source of truth)

2. We could look at the error messages that come back from npm and ignore them if they are 403's with the message saying you cant publish over an existing version

* ✅ moderately safe, since we know there **must** be a mistake on npm side since we must have **just** run and `npm info` which gave us conflicting info
* 🚫 feels slightly risky as it's ignoring what *could* be a legitimate error (race condition in a package being released in two places at once).
* Not possible in atlaskit, but possible in other places?

3. We could change the way publish works and take an *explicit* list of packages to publish and ignore the others

* 🚫 This would remove some of our auto-recoverability which would need to be solved another way
* 🚫 Would be a breaking change to current

Personally, I'd lean towards option 2. Happy to put it behind a flag if necessary though.

Thoughts?

Start with the bolt publish flow, especially where it runs npm info and handles npm publish failures. Review the three options in the issue and the discussion before choosing a direction; the work is done when the selected behavior prevents this replication scenario without hiding unrelated publish failures.

Written by the indexing model from the issue text.