This PR removes the localisation functionality from Flotilla, and instead moves responsibility to ISAR to maintain localisation. This means that currentArea on the Robot model is no longer used in mission logic. Additionally, we are no longer using Areas to keep track of whether a robot can start a mission, but Deck. The Deck is in this case referred to "InspectionArea" since we want to move towards having a model which stores a list of areas the robot can move in. Temporarily Deck is used for this purpose, but should be generalised in the future.

Some other things to note: Map information is not included in the IsarMissionDefinition for missions that do not have corresponsing MissionDefinitions. This is fine as this value is only used for inspection metadata, and the missions which do not have MissionDefinitions (return home and emergency dock missions) do not gather inspection data anyways.

We are still sending startPoses in the isar missions, using the DefaultLocalizationPose found in Decks. This is temporary as in the future we want this Pose to be stored in Isar instead. We are also still sending the dock and undock flags in the mission. In the future we should not need to send these as Isar should know to dock when the mission is a ReturnHome mission and to undock when its last mission was a dock mission.

One known "bug" currently, which I will assign to its own issue, is that the dock mission is also run even if the robot is currently docked. The simple solution to this is that ISAR should anyways be aware whether it's docked and so we don't need to do anything if we receive a return home mission when already home. In Flotilla in the future we can avoid sending it, if we implement a telemetry from ISAR which states whether the robot is docked or not. Currently, before this PR, we guessed whether it was docked using the robot.CurrentArea value. This has been replaced by robot.CurrentInspectionArea, which is set when the robot runs a mission for the first time, and then never unset again. To move the robot to another installation or to a separate region of the same installation which is in another inspection area, we currently want to use swagger to do so, as this is not something the user should be able to do.

Ready for review checklist:

• A self-review has been performed
• All commits run individually
• Temporary changes have been removed, like console.log, TODO, etc.
• The PR has been tested locally
• A test have been written
  • This change doesn't need a new test
• Relevant issues are linked
• Remaining work is documented in issues
  • There is no remaining work from this PR that require new issues
• The changes does not introduce dead code as unused imports, functions etc.