use pkgdepends syntax for gitlab remotes with pak

[kevinushey]

Fixes #2180.

Problem

renv_record_format_remote(pak = TRUE) formats GitLab records using renv's own
remote syntax, which pkgdepends cannot parse:

testpackage=gitlab@gitlab.example.de::bioinf/rlib/testpackage@babda05...

pkgdepends' GitLab grammar (pkgdepends:::gitlab_rx()) is:

[<package>=]gitlab::[<protocol>://<host>/]<group>/<project>[/-/<subdir>][@<commitish>]

so there are two bugs here, both confirmed by passing renv's output to
pkgdepends:::parse_pkg_ref():

1. Custom host: hard failure. gitlab@host:: is unparseable, which is the
   Cannot parse package error reported in renv::restore does not resolve packages on self-hosted Gitlab instances when using pak #2180. Note the host has to be
   spelled as a URL: gitlab::gitlab.example.de/group/repo parses
   "successfully", but treats the hostname as the first path component and so
   looks for the project on gitlab.com.

2. Sub-directories: silent misparse. renv emits
   gitlab::group/repo/subdir@sha, which pkgdepends reads as project subdir
   within group group/repo -- installing the wrong thing rather than erroring.

This doesn't reproduce for everyone because packages installed by pak carry a
valid RemotePkgRef in their DESCRIPTION, which renv_record_format_remote()
returns early and unchanged. The failure only affects lockfile records generated
by renv's own resolver -- which is the lockfile shape reported in #2180.

renv::install("gitlab@host::...") was broken the same way on a separate path:
renv_pak_install() passes raw user specs to pak untouched, apart from the
: -> / sub-directory fixup from #2011, which is itself wrong for GitLab.

Changes

• renv_record_format_remote_pak_gitlab() formats GitLab records in
  pkgdepends' syntax. It always includes https://<host>/ (also for
  gitlab.com, which removes the sub-directory ambiguity), uses /-/<subdir>,
  and keeps an explicit <package>= prefix, since pkgdepends would otherwise
  infer the package name from the last path component.

• renv_pak_remote() translates user-provided GitLab specs on the install()
  path. Specs renv can't parse, and merge-request specs (#42, which has no
  pkgdepends equivalent), are passed through unchanged so that pak can report
  the problem itself.

Validation

• Every generated remote now round-trips through
  pkgdepends:::parse_pkg_ref() with the expected url / subdir / commitish /
  package.

• End-to-end against gitlab.com with pak enabled: install() -> snapshot()
  -> restore(), plus a restore() from a renv-resolved record with no
  RemotePkgRef (the shape from the issue). Both install correctly, including
  the subgroup case renv-group/renv-subgroup/subpackage. The self-hosted host
  itself can only be validated at the parse layer, which is where the reported
  error is raised (get_remote_types(refs)).

Not addressed

Two adjacent cases fail for the same reason, but need decisions beyond the
scope of this fix:

• GitHub Enterprise. github@host::user/repo is equally unparseable, and
  github:: has no host slot in pkgdepends at all; the only route is
  pkg=git::https://host/user/repo.git@sha. That needs host translation
  (renv records an API host, e.g. github.example.com/api/v3) and git::
  supports no sub-directory. tests/testthat/test-records.R:208 currently
  asserts the broken output.

• Bitbucket, svn. pkgdepends has no such sources
  (Unknown package source: "bitbucket"), so these could only work via a
  git:: URL rewrite.