Support appId when publishing to Posit Cloud

[mbaynton]

deployApp() includes the parameter appId whose intended usage is to allow publishing to a specific existing output on the server. This functionality needs to be given some love when the destination is Posit Cloud:

• Posit Cloud has a notion of an "application", but its ID is intentionally difficult for a user to track down because we prefer instead to
  expose related construct "content" to users. Work happening right now to support a history of prior revisions to some types of published content in cloud also makes the relationship between a Cloud "content" and a Cloud "application" not one-to-one -- each time you publish a new revision, you use the same content ID but get a new application ID. For all these reasons, to allow the user to publish to an existing output in Cloud without a .dcf deployment history, they should be providing the content ID, not the application ID.
• As a result of the above, in the case where a deployment history is available, we're already written rsconnect code that switches to persisting the content ID rather than the application ID. I suggest this work merges before tackling this issue, and then we fix remaining problem(s) with manually passing a Cloud content ID:

1. Manually passing a content ID (e.g. deployApp(appId='lucid:content:123', ...)) fails with

   Error in (function (..., row.names = NULL, check.rows = FALSE, check.names = TRUE,  : 
   arguments imply differing number of rows: 1, 0
   

2. Perhaps we should always consider any value passed to appId to be a content ID if the server is posit.cloud, even if not made explicit with the lucid:content:?

[kippandrew]

I'd like to propose a third option that is similar to open 2:

3. Consider deprecating the appId parameter in favor of a new contentId parameter. I think this would work well for Posit Connect and Posit Cloud, both of which have the concept of contentId though there are differences (see my comment here: deploymentTarget doesn't work as intended with Posit Cloud #808 (comment)). However, shinyapps.io doesn't really have the same concept, but maybe it would be acceptable to have contentId mean appId when used with shinyapps.io.

[mslynch]

We decided on passing the unqualified content id in appId (deployApp(appId='123', ...)) – this will work when we implement static publishing. We'll also ensure backwards compatibility with old dcf files using application id through #821.

[mslynch]

Reopening – the error arguments imply differing number of rows: 1, 0 is a regression on main, unrelated to any content id/app id changes. cc @hadley

[hadley]

I'll take a look this afternoon.