Save deployment refactoring

[hadley]

This is a refactoring that shouldn't change behaviour compared to released rsconnect.

I verified expected behaviour using this script:

1. Create a new project called testdeploy{random number}
2. Create empty index.Rmd
3. Call rsconnect::deployApp().
4. Deployment should succeed & app opens in browser
5. Call rsconnect::deployApp() again.
6. Deployment should succeed & app opens in browser
7. Run rsconnect::forgetDeployment() and press enter.
8. Should be prompted to confirm that existing app is the same one.
9. Call rsconnect::deployApp() again.
10. Deployment should succeed & app opens in browser

[hadley]

I have made a small behaviour change in the interests of making the user feedback more actionable — if you say you don't want to update the existing app, it now creates a new app.

[hadley]

Ooops, I should have tested that before implementing — connect requires unique names.

[hadley]

Re-tested and back to the original behaviour, but with better user feedback.

[aronatkins]

What is the workflow when rsconnect discovers a default target that has been deleted on the server? The target produced by deploymentTarget has only considered on-disk state, which may be stale?

[aronatkins]

What should happen if the target app ID has been deleted? The old flow would leave app = NULL and try some other option.

[hadley]

I just tried it out, and I think if the application id no longer exists, then getApplication() will error with a 404. That's probably worth considering in more detail (and I'll add a fall back in case getApplication() does return NULL in other cases), but I think it's out of scope for this PR.