Propagate CRS and geometry column from Shapefile.Table via DataAPI

[asinghvi17]

Does what it says on the tin, and tests that DataFrame(table) retains these values.

We currently use the :note style meaning that the value of the metadata is propagated through any transformation of the table. This is up for discussion (for reference, GeoDataFrames.jl uses :default styling, which is invalidated if the dataframe is transformed.).

The only operations I can see might have a problem with this are:

• Changing the geometry column in a dataframe (when would you do this anyway?)
• Reprojecting geometry (we can make GeometryOps switch the metadata for us, though).

[asinghvi17]

This test was failing before the writer change and I don't entirely understand why:

write tables: Test Failed at /home/runner/work/Shapefile.jl/Shapefile.jl/test/table.jl:55
  Expression: all(isequal.(replace.(skipmissing(a), !isascii => (x->begin
                        #= /home/runner/work/Shapefile.jl/Shapefile.jl/test/table.jl:56 =#
                        '_' ^ textwidth(x)
                    end)), skipmissing(b)))

https://github.com/JuliaGeo/Shapefile.jl/actions/runs/10305538693/job/28526609515?pr=118#step:5:846

[rafaqz]

This generally looks good.

But before we merge it I think we need a PR to GeoInterface.jl adding this specification to the docs, so it can be discussed as an ecosystem change rather than a PR to Shapefile.jl. I imagine @evetion and @visr will have some input to add.

[evetion]

Using :note is somewhat better indeed, the :default style for GeoDataFrames is lost as soon as you subset the table, I might change that.

Implicitely, stuff that (re)projects should check/set the crs, so either take a DataAPI dep, or add the dep to GeoInterface.

Lastly, there's colmetadata, and especially for multiple columns, it makes sense to have the crs (also?) on the column level.