Add option to modify an `AbstractFeatureLayer` from an object implementing the Tables.jl interface

[mathieu17g]

Investigate the possibility and interest (cf. https://github.com/yeesian/ArchGDAL.jl/pull/238#issuecomment-930769271) to modify an AbstractFeatureLayer from an object implementing the Tables.jl interface via not copying fields and geoms of an AbstractFeatureLayer when converting it to a table.

Here are some thoughts for discussion. It may suppose to:

• enrich GDAL Field wrapper with an IField type
• export to table, fields as wrapped GDAL objects as it is done currently for geometries
• handle the Garbage Collection of the table and maybe some dataset writing synchronizations
• find a mechanism preventing users to make unwanted trailing modifications to the AbstractFeatureLayer. Maybe with a do block style Table.rows and Table.columns to protect the AbstractFeatureLayer from trailling modifications

[yeesian]

(Just tossing out some thoughts not necessarily helpful to implement what was described in https://github.com/yeesian/ArchGDAL.jl/issues/247#issue-1013215922, but to understand whether it should be pursued and how it might be implemented.)

At its heart, it sounds like it's proposing a new type corresponding to a FeatureLayer. To scope out the design, it might be helpful to clarify when users will prefer to use it over the alternatives:

1. using the ArchGDAL.FeatureLayer
2. materializing to a DataFrame/Table in Julia (e.g. GeoDataFrames, GeoTables)

It sounds like the feature/vector counterpart of DiskArrays / GeoData in the raster setting of

1. using ArchGDAL.Dataset and ArchGDAL.RasterBand,
2. materializing to an array/image in Julia,
3. using DiskArrays.

My guess is that such an offering will be compelling if it's able to provide the ergonomics of using DataFames without making copies of the data:

• One option is to operate on GDAL objects, and implement operations through the GDAL API as described in https://github.com/yeesian/ArchGDAL.jl/issues/247#issue-1013215922.
• Another option is to provide a SQL-like interface such as https://geoalchemy-2.readthedocs.io/en/latest/. One way of doing it using GDAL's executeSQL (documentation on the available SQL dialects): if it's helpful, here's non-published documentation on using Spatialite through ArchGDAL if Spatialite support is available in GDAL.jl. See also: https://discourse.julialang.org/t/implementing-sqlite-spatialite-driver.