Remove StaticArrays dependency

[visr]

Change Coord from being a SVector{4, Float64} alias to a struct implemented here. This struct is now mostly internal, since tuples are always returned from transformations. Length of the output tuple still depends on the input length. SVectors still work as input coordinates, just like tuples, vectors, and multiple arguments f(x, y).

I included a benchmark here that shows that performance is good:
https://github.com/JuliaGeo/Proj4.jl/blob/a2e71c159a5892b0986e1b933fe0ff405ce940a2/test/benchmark.jl

This is the same benchmark as used here: #51 (comment). For types like SVector or tuples the return type (tuple length) can be inferred precisely, for Vector it infers Union{NTuple{2,Float64},NTuple{3,Float64},NTuple{4,Float64}} which is as good as we can expect.

This is on top of #57, but since it changes the return type of transformations I wanted to put it up separately for review. I think after this #57 would be ready for release, I was thinking to make it Proj.jl v1, such that we can actually start using the minor version number for features.

[asinghvi17]

I think that the change makes sense, and I don't use the Coord interface at all on the GeoMakie end. If performance is the same then I don't see any reason not to merge, especially if it simplifies the API (and makes it more intuitive for other users).

However, there is an issue here when used with GeoMakie. Specifically, given a transform t,

julia> t(Point2f(1, 2)) |> typeof
Tuple{Float64, Float64}

It seems like the Transformation is not respecting the datatype or eltype of its input, which IMO should be changed. This did break GeoMakie when I tested it.

[visr]

Thanks for having a look, and good point about the return type. Returning the same type was originally a design goal, see also old discussion here. It looks like on top of this refactor it's really as easy as #65.