Fix/mission item altitude

[TimonSchreiber]

Fixes #107

Changes

• New MissionNode.Home stores the seq 0 home item as metadata at node index 0. It is excluded from the DJI mission and re-emitted in MAV_FRAME_GLOBAL on download. Node index continues to equal MAVLink seq.
• Item assembly returns a sealed ItemAssemblyResult instead of a Boolean, enabling MAV_MISSION_UNSUPPORTED_FRAME NACKs. Only MAV_FRAME_GLOBAL_RELATIVE_ALT(_INT) is accepted for coordinate items; AMSL is rejected rather than converted, since MSDK v4 provides no reliable home AMSL reference.
• NAV_TAKEOFF is materialized as the first DJI waypoint, so the initial climb targets the planned takeoff altitude. Takeoff items with (0, 0) coordinates are rejected at upload. The waypoint count is derived from the builder's waypoint list.

Branched off #112 and intended to be merged after it, since both touch the mission upload path. Will rebase onto develop once #112 lands.

[angel-ayala]

Nice work @TimonSchreiber , the only comment that I have is regards the title. The addressed changes make sense to me, but were focused on mission items altitude instead the aircraft take off. So I will update the PR title.

I agree that #112 must be merged first.

What worries me the most is if such changes were already tested with the aircraft.

I was also aimed to address the problem with the altitude during take off, focused on the take off action that can be triggered from QGC, but I haven't tested it yet. I will open a PR of such changes to check and compare in case of requiring to update other lines.

[TimonSchreiber]

Definitely a better name for this pr.

Do you mean, you are worried to approve this without tests or what the latest test flights say about this problem?

[angel-ayala]

Yes, my worry is about approve the PR without testing. But if all seems to be ok, maybe a new PR can be opened with a better fix.

[angel-ayala]

Nice work, everything seems to be ok. Ready to merge.