Slim down GeometryBasics and remove all type complexity

[SimonDanisch]

For a summary of changes in the 0.5 release, see #226 (comment) or the release tag

---

So... I tried for a very long time to create a Geometry package that serves all use cases and can be used as a foundation for all other Geometry packages without any performance problems for any domain. This never really worked out for a bunch of reasons.
While GeometryBasics was never used that way, all the ideal requirements I aimed for have turned GeometryBasics into a very overengineered package, with long compile times and complex types.
I never really had a lot of time to actually maintain and grow it though, so on top of being overly complex it has been poorly documented. I also tried to integrate lots of types like LineStrings, which I don't know very well and when to use them :D
So, this PR is slimming down GeometryBasics to the very basics that I need in Makie, which should help a lot with compile times and maintainability.

It changes:

• removes all kind of meta infrastructure, only leaving a simple MetaMesh type that can hold e.g. uv and normals
• remove table interface
• less type artistry and instead tries to use the most simple types as possible
• copies more instead of creating horrible types like StructArray{ReinterpretArray{SubArray{Int64, 1, Vector{Int64}, Tuple{UnitRange{Int64}}, true}}} (this is even shortened :D )
• Make Point +/-/* Vec consistent

Fixes:

• Meshing a single triangle sometimes returns an empty mesh #158
• Ambiguous NgonFace constructors #151
• Mesh with tris and quads? #142
• merging an empty vector of meshes / creating an empty mesh #136
• Why are Multi{Polygon,Linestring,...} <: AbstractVector and not <: AbstractGeometry #95
• FaceView docstring example does not work #81
• Long type info #60
• Polygon is sequence of segments, not points? #13

Will not be in the scope of this package anymore:

• Redesigning Metadata processing and creating of meta-geometries  #71
• heterogeneous geometry collection #50
• heterogeneous feature collection #49
• StructArrays interface for points #29
• Static analysis of a Type #31
• Better show methods for triangle faces #26

[evetion]

This is some good cleanup! This is on top of #169 right?

Over at JuliaGeo/GeoInterface.jl#33, we're now (finally) finishing a new Traits based interface. This gets rid of all the required subtyping on GeoInterface.Geometries and I would like to update the GeoInterface implementation in GeometryBasics here as well.

In that context, I see you removed LineString and changed the decomposition in this PR. In GeoInterface we still assume a Polygon decomposes into 1 or multiple LineStrings like instances (exterior ring and any interiors), which themselves decompose into Pointlikes. Do you think we could still make that work in this PR? Would Line be a proper replacement, or is it just two points?

[SimonDanisch]

Yes, I think we can bring it back, if we document a bit better what its supposed to be used for!
I think we should keep them as simple as possible, so maybe something like:

struct LineString{N, T}
   line::Vector{Point{N, T}}
end

struct MultiLineString{N, T}
   lines::Vector{LineString{N, T}}
end

[evetion]

@SimonDanisch Is it ok to revive https://github.com/JuliaGeometry/GeometryBasics.jl/compare/master...visr:rfc?expand=1 on the current master of GeometryBasics? Or would you like me to open a PR, based on the changes in this PR? Also depends on your expected timeline of this PR?

[SimonDanisch]

No, that sounds great :) Looks like it has 0 dependencies, so that makes things a lot easier ;)
I think master is fine... It's such a small diff, that it should be easy enough to rebase in this PR.

[evetion]

No, that sounds great :) Looks like it has 0 dependencies, so that makes things a lot easier ;) I think master is fine... It's such a small diff, that it should be easy enough to rebase in this PR.

Ok 👍🏻 , I've made a first attempt over at #175.

[SimonDanisch]

I'm going to merge this, to clean up pending pull requests etc.
This doesn't mean it's 100% ready, I expect a bit more polish for the docs, and maybe a few more little clean ups once we use it more.