fix: do not require libs.versions.toml alias names

[kdroidFilter]

🚀 Description

Stop looking up the consumer project's version catalog when adding kotlinx-coroutines. The plugin now always injects those dependencies by Maven coordinates, using a plugin-owned default version.

📄 Motivation and Context

Fixes #26.

Published 0.6.0 resolves kotlinx-coroutines-core (and related artifacts) from the consumer libs catalog via Optional.get(). A fresh KMP project — or any catalog that names the same library differently, e.g. kotlinx-coroutines instead of kotlinx-coroutines-core — fails Gradle sync with No value present.

Plugins must not impose naming conventions on libs.versions.toml.

🧪 How Has This Been Tested?

• Reproduced the published 0.6.0 failure e2e:
  • Fresh-AS-style catalog (no coroutines aliases) → No value present in Libraries.kt:7
  • Catalog alias kotlinx-coroutines instead of kotlinx-coroutines-core → same crash
• After the fix, the same consumer layouts configure and generate bridges:
  • no version catalog
  • AS-style catalog without coroutines aliases
  • renamed kotlinx-coroutines alias
• Added TestKit coverage for those three layouts (help + generateKneNativeBridges)
• :examples:calculator:generateKneNativeBridges still succeeds

📦 Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

✅ Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.