…ateContainer) and an immutable representation of the state of the map (FlutterMapState)

… FlutterMapStateContainer to InteractionDetector

- Replaced mapState getter with the various getters which were just
proxied to MapState.
- Heavy refactoring (hopefully without changing behaviour) of gesture
  code.

In passing I have simplified

…nce methods for checking single flags

…ch move when only pinch zoom is enabled

This stops the following message from being spammed in tests which was
caused by a problem with the http mocking:

type 'Null' is not a subtype of type 'Future<HttpClientRequest>'

In doing so I noticed that the adaptive boundary options could use a
refactor and so placed them in a dedicated class which led to a tidy up
to the boundary code in FlutterMapState.

…le MapBounds class

FrameConstraint unites the various methods of setting a maximum bounds
for the map frame. Previously MapOptions had three different concepts
for setting a max bounds: adaptive bounds, maxBounds and se/nw pan
boundaries. Adaptive bounds and maxBounds are now
FrameConstraint.contain whilst sw/ne pan boundaries is replaced by
FrameConstraint.containCenter.

FrameFit is a replacement for FitBoundsOptions, combinining the options
with the bounds. This means bounds/boundsOptions now become
initialFrameFit (since bounds/boundsOptions were actually initial bounds
and the options for those initial bounds). Additionally this sets up an
abstraction for different map fits since coordinate fit will be added
next.

This commit incorporates @jjoelson's coordinate fit implementation in to
the new FrameFit abstraction.

Co-authored-by: Jonathan Joelson <[email protected]>

…lection to tidy up options and change how options are propagated in preparation for changing the inherited widget to an inherited model

…of coordinates doesn't have an unambiguous meaning

These old adaptive constraints did not prevent the map from going
outside of the specified bounds, they stopped the center of the map from
going outside of those bounds. This commit sets the constraints
appropriately.

…es, unless InteractiveOptions is not provided

… relevnat aspect changes

…t the widget state

… MapOptions

In passing re-ordered the methods in MapControllerImpl to match
MapController.

Improved some documentation (part 1)
Prevent public exposure of `FitCoordinates` and `FitBounds` constructors

…idy up documentation

None of the fields which were on the CameraFit base class were
conceptually essential for any imaginable camera fit. Moving them to
the subclasses ensures that any future camera fits will not need to
implement those options just because they already exist. It would also
allow for individual camera fits to specify different default values if
appropriate.

The plugin API no longer exports classes which flutter_map already
exports.

Imports within this package now import the actual classes they use
rather than the whole flutter_map library. Internal code should not
depend on the exported library definition.

The other parameters for CameraFit all have default values which will
not cause changes to the calculated CameraFit (i.e. padding is zero,
forceIntegerZoomLevel is false). Setting maxZoom to null makes it
consistent with the other parameters in that it will not affect the
calculated CameraFit. I chose null over double.infinity as in my opinion
the intent is clearer, no maximum.