py: merge the asyncio wrapper into the mavsdk package

[julianoes]

Makes aiomavsdk a submodule of mavsdk rather than a second distribution:

Before	After
pip install mavsdk4 → import mavsdk	import mavsdk
pip install aiomavsdk → import aiomavsdk	import mavsdk.asyncio

One package, two interfaces. This is what projects owning both interfaces normally do — redis.asyncio, sqlalchemy.ext.asyncio, pymongo.asynchronous — and it means users choose an interface at import time instead of choosing a package before they understand the difference. The aio* prefix convention exists mostly for wrappers around someone else's sync library, which is not the case here.

Neither distribution has ever been published to PyPI, so nothing external breaks.

Notes for review

No changes were needed inside the package. Everything already imported either relatively or absolutely from mavsdk.*, and both keep resolving once the package sits underneath mavsdk. The diff is 101 files but almost entirely renames — only the codegen script, the READMEs and two stale docstrings have real content changes.

import asyncio inside mavsdk/asyncio/ still gets the standard library, since Python 3 imports are absolute. Verified rather than assumed.

mavsdk/__init__.py deliberately does not import the submodule, so import mavsdk does not drag in the asyncio machinery, and there is no import cycle.

Code generation is now one script for both flavours, with templates split into templates/sync and templates/asyncio. The two scripts previously differed only in an output path and a ruff path — an easy way to add a plugin to one and forget the other.

Verified

• import mavsdk and import mavsdk.asyncio both work; mavsdk.asyncio.Mavsdk and mavsdk.asyncio.System resolve.
• Sync and asyncio plugin trees have identical sets (36 plugins each), before and after.
• A wheel builds containing both trees under a single mavsdk top-level.
• Everything under mavsdk/ compiles.

One caveat: I could not exercise the generated plugins at runtime here, because the prebuilt libcmavsdk.so in my tree predates Action::set_home and rebuilding it needs a full libmavsdk rebuild. Both mavsdk.plugins.action and mavsdk.asyncio.plugins.action fail identically on that missing symbol, which shows the move is neutral, but CI building against a current library is the real check.