`.gpkg_process_sources()` should be more robust to various OGR sources

[brownag]

Currently just a small number of file path extensions for raster and vector data are used to identify paths to possible spatial data sources.

Nobody has complained, and I guess it has worked fine for me, but I should have generalized this a long time ago...

I am now thinking perhaps the functionality to support and classify arbitrary file paths in the same call to gpkg_write() might be too general. The main reason using file extensions is necessary is because either terra::rast() or terra::vect(), or a non-spatial table function, needs to be called based on whether a file input is determined to be is a raster, vector, or attribute.

• Can I create a lookup table of file extensions from file based sources found in terra::gdal(drivers=TRUE)?

• Could I pass an argument so that user needs to specify whether they are writing raster, vector, or attributes? Meaning 1 type per call, or a vector of equal length to the input list denoting data type? Both of these alternate options seem rather cumbersome in comparison to how it works now.

[brownag]

A semi-related issue is that it may sometimes be desirable to transfer between OGR sources without reading them into memory. Minimal support for querying and writing a SpatVectorProxy for an arbitrary source was added in https://github.com/brownag/gpkg/commit/8f3cae479dec4d0f8166ab51926893fe3b4658f0... but a more general solution would use an ogr2ogr-like interface, rather than going through a SpatVector/R intermediate object.

[brownag]

This could probably be resolved using {vapour}!

system.file("ex","lux.shp",package="terra") |> 
  vapour::vapour_driver()