Improve handling of NaN values

[hjabbot]

Moving here from project repo #83.

This could go into MeshiPhi, but I personally think that NaN's are perfectly valid in meshes, so anything downstream should handle NaN's gracefully. Issue is NaNs and Infs aren't natively supported by the JSON schema so strictly speaking they shouldn't be in the output of MeshiPhi meshes, but it seems dangerous to equate NaNs to a real value.

---

NaN values in the mesh shouldn't be allowed to reach the route planner as they will cause errors that may be difficult to debug. Currently NaN values are filtered out within the vessel performance class and all NaN values are set to zero. We should consider whether this is the correct approach in all cases and identify where NaN values might arise and how their propagation could be avoided.

[SamuelHall700]

Currently, all NaN's in a mesh are set to 0's by the vessel performance modeller.

With the refactoring of the route planner, we plan to remove this from the vessel performance modeller and have them handled more gracefully by the route planner. This work is still ongoing

[thomaszwagerman]

See bas-amop/MeshiPhi#95, also relates to bas-amop/PolarRoute-server#119, bas-amop/PolarRoute-server#120.

While the performance modeller does set to 0, a consistency issue arises when the meshes are imported into a PostgreSQL database. A format natively supported by JSON would prevent issues.