Resolve "Update platform status to accommodate simulated wpts"

Closes #78 (closed)

examples/mas-dt/waypoints_geojson.json

 {
     "header":{
-        "message_ID": "b427003c-0000-11aa-a1eb-bvcdfghjgfdd",
+        "message_ID": "b427003c-0000-11aa-a1eb-b1cdf2342fdd",
         "timestamp": "2024-09-05T00:00:00Z",
         "version": "v2.0.0-beta.1",
         "source": "noc-sfmc",

examples/mas-dt/waypoints_props.json

 {
     "header":{
-        "message_ID": "b427003c-0000-11aa-a1eb-bvcdfghjgfdd",
+        "message_ID": "b427003c-0000-11aa-a1eb-b1cdf2342fdd",
         "timestamp": "2024-09-05T00:00:00Z",
         "version": "v2.0.0-beta.1",
         "source": "noc-sfmc",

[Dan Jones]

@owanes - done what we discussed yesterday.

• waypoint_status shares the same format as platform_status so we only need one parser in c2 land
• waypoint_status requires either waypoint or waypoint_latitude + waypoint_longitude
• platform_status requires either position or latitude + longitude or no_position_reason which is an enum.

I'm still a little concerned about the one parser idea because we want to include the current waypoint in the platform_status for ORI but I don't think we want to ingest the waypoint from every platform_status into positions

[Dan Jones]

After more talk we've gone back to preferring simulated platform_status for this since during the surface dialog after transferring and re-reading the ma files there should be another real platform_status containing the new waypoint.

We can use the changes in the platform_status message in this MR for that purpose but we decided to leave the waypoints message in place for now but with no immediate plans to use it.