Eliminate abstract classes

[1ec5]

We should eliminate the two abstract classes that this library defines, DirectionsOptions and DirectionsResult.

These classes are only abstract by convention due to language constraints. There’s a risk that developers will mistakenly create instances of DirectionsOptions and attempt to use them in place of the similarly named RouteOptions. Making matters worse, these abstract classes implement static functions required by protocols such as Equatable, robbing concrete subclasses of the ability to provide their own implementations: #382 (review).

RouteOptions and MatchOptions are essentially value classes, which don’t benefit from reference semantics, so they should be converted to structures. Converting Waypoint and Tracepoint into structures (#388) paves the way to do the same with RouteOptions and MatchOptions. It will be possible to reuse a single RouteOptions instance for two Directions API requests without worrying about crosstalk between them after modifying Route.options (or RouteResponse.options after #391).

Route and Match are large, complex classes that may need reference semantics, especially once we implement route refreshing: mapbox/mapbox-navigation-ios#2284. We can convert DirectionsResult into a protocol that both Route and Match conform to. There would be quite a bit of duplication between the two classes. We may be able to mitigate some of the duplication by extending DirectionsResult with default method implementations, but that won’t be possible in all cases, due to interdependencies between properties and methods.

/cc @mapbox/navigation-ios

[JThramer]

Blocked by mapbox/mapbox-navigation-ios#2350, in progress.

[dersim-davaod]

I'll try to handle the task as we agreed with @1ec5 and @Udumft it's a good starter issue for a newcomer.