Convert core module to Kotlin Mutliplatform

[Fabi755]

This PR is migrating the core module to Kotlin Multiplatform.

Breaking changes

• Instead of using android.location.Location we have now our own generic org.maplibre.navigation.core.location.Location.
• Module libandroid-navigation renamed to maplibre-navigation-core (important for Jitpack reference)
• Package org.maplibre.navigation.android.navigation.v5. has renamed to org.maplibre.navigation.core
• You can still use MapLibreNavigation, but there it's now required to set a LocationEngine. Alternative using AndroidMapLibreNavigation / IOSMapLibreNavigation for a default implementation of this parameter.
• ...

---

Some key facts

• I moved out the UI related classes to the UI module, as it was wrong placed and using context and other Android platform related classes.
• The logic was very very mixed with the NavigationService, Notification and Android specific threading. I don't see a reason to keep this, I switched the threading to coroutines, and the notification and foregrounds service are now optional components, that included in the UI module. The navigation core logic is now located in navigation.engine package. The notification is now located in the UI module in navigation package
• As the module contains android, I renamed the module to maplibre-navigation-core
• As the package contains android, I renamed the package from org.maplibre.navigation.android.navigation.v5. to org.maplibre.navigation.core
• The only platform specific part is the location fetching. I solved this by an interface implementation.
• The tests can only run on JVM(/Android) target, because we are using currently the mockk library

Platform specific logic

Two categories of platform specific parts are affected this module.

**1. the location logic.*+ I'm very happy with the solution around the LocationEngine and the platform specific logic.

2. the MapLibre library / GeoJson / Turf logic. I'm very unhappy with the geojson stuff. I now added a new module maplibre-navigation-geo that holds some partial (simplified) copies of the geojson and turf stuff. The original repository maplibre-java are used before by the Android client. But Java code can not included to iOS with KMP.

I see three solutions for this:

1. Adding own module that gives interfaces and using internally the Android & iOS MapLibre-Native libraries.
2. Convert maplibre-java also to a KMP project
3. Keep the current solution and having our own GeoJson module.

All of this points having up- and downsides. I choosed now the 3. point, because it was the fastest. I would suggest to create a follow up issue and discuss this here.
To find a solution, we need also input from the maintainers of maplibre-java and needing also a look to the iOS side, and how we implement this core module.

Performance

I changed a the whole logic structure, that was necessary to remove all Android related things, and using plain Kotlin. I tried my best to keep it simple and efficient. But I think we all should do some performance tests with real navigations and real-life example usages.

[Fabi755]

How we want to continue here?

From my side all things are done, and we now published a pre-release (org.maplibre.navigation:navigation-core:5.0.0-pre0).

Do we want keep this open, and also wait until the GeoJSON library (maplibre-java) is ready. And afterwards also the MapLibre native?

Or do we want merging this now, and keeping on pre-releases (or not?) until all the other stuff is done?

---

I would personally prefer the latter. Then we can continue development, without having this too big PR open.

[boldtrn]

In my opinion we should merge this sooner rather than later (same for the maplibre-java). It will just get messy. The current state seems to work reasonably fine already and if we find a bug, we can create a new PR? The PR IMHO is probably too big for most people to review anyway, so we just scare people off with this 😄.

[boldtrn]

From my side, I would be fine with merging this. It's a huge change but so far all testing looks good.