WIP: use pak instead of confirm_deps for dependency installation

[infotroph]

Description

EXPERIMENTAL, NEEDS TESTING: Use pak::local_install_deps() instead of our confirm_deps script.

Before merging, need to show that local_install_deps (1) behaves the same as confirm_deps with respect to installation behavior, and (2) does not query overeagerly for updates to dependencies. Recall that the original impetus for confirm_deps was devtools::install_deps making too many queries to remote repos that we'd already checked earlier in the process. My read of the documentation suggests we should expect pak to be better about this, but I have not yet checked. Probably the easiest way to check would be by running the install process inside a container instrumented to monitor outgoing IP requests.

Motivation and Context

Review Time Estimate

• Immediately
• Within one week
• When possible

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• My name is in the list of CITATION.cff
• I have updated the CHANGELOG.md.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[infotroph]

When testing: Check whether pak retains the same behavior as remotes::install_deps with respect to choosing a CRAN repository, viz. 'try repositories in the order they are specified and stop when the version requirement is satisfied, even if a newer version is available from a repo later in the list'. We rely very heavily on this behavior to avoid version hell in the older rocker images.

[infotroph]

Closing this until I have a chance to actually test it -- #3366 seems to have fixed the biggest current pain point in confirm_deps, so I'm no longer in as much of a hurry to replace it.