Enable dbc to install off-registry drivers from GitHub repos

[ianmcook]

It would be nice if dbc had a way to install off-registry drivers from GitHub repos, like dbc install user/repo. This would depend on there existing a latest release tag in that repo with the prebuilt shared libraries as release assets. dbc could install these (and their manifests) under correspondingly named subdirectories of the usual places where drivers are installed. Then the driver managers could take driver="user/repo" and everything should just work. This would be a great way to get experimental ADBC drivers like @tokoko's driver for Iceberg into users' hands more quickly.

This is inspired by how pak works in R.

I think the hardest part of this is documenting how third-party driver developers should set up GitHub Actions to build their drivers for all platforms on each release and include the shared libraries in the release assets.

[amoeba]

• Check if driver manager spec manifest supports x/y hierarchy (we think profiles do but manifests do not?)
  • Should probably document this explicitly for manifests and profiles
  • Ian checked and this appears to work in at least Rust and other driver managers
• To do this we'd need to document the unresolved MANIFEST we use in our archives
• We need to document the release artifact name convention (drivername-os-arch-version quad)
• Document we require the release tarball needs to be flat

[ianmcook]

Maybe the syntax should just be dbc install github.com/user/repo so we're not privileging GitHub and we're not foreclosing the future possibility of having hierarchically organized packages on the default registry.

Or alternatively dbc install @user/repo? That's clearer and more consistent since we could name the directory where the driver is installed @user, enabling driver managers to load the driver with driver="@user/repo".