feat: richer Astra database creation (database_type and pcu_group_id)

[erichare]

Summary

Closes #408.

Database creation through AstraDBAdmin.create_database / async_create_database previously hard-coded two things in the DevOps payload: dbType: "vector" and the absence of any PCU-group assignment. This PR exposes both as optional, keyword-only parameters so the client keeps pace with recent Astra platform capabilities:

• database_type (default "vector") — selects the database flavor.
  • Default preserves today's behavior (a vector-enabled database).
  • Passing None omits dbType entirely, letting the DevOps API apply its own default — this is what enables non-vector databases.
  • Any other string is forwarded as-is. The value is intentionally not coerced or validated, so newly-introduced database types can be requested without waiting for an astrapy release (same conservative philosophy as the DatabaseStatus enum).
• pcu_group_id — assigns the new database to a PCU group (pcuGroupUUID) at creation time. Omitted when not supplied.

This dovetails with the existing pcu_types groundwork in find_available_regions ("until full PCU support").

Backward compatibility

Fully backward compatible. Both parameters are optional and keyword-only; existing callers (create_database(name, cloud_provider=..., region=...)) continue to get a vector database with no PCU group and an unchanged payload.

Payload behavior

Call	dbType	pcuGroupUUID
create_database(...) (default)	"vector"	(omitted)
create_database(..., database_type=None)	(omitted)	(omitted)
create_database(..., database_type="tabular", pcu_group_id="…")	"tabular"	"…"

A note on the design (for reviewers)

The issue proposed a DatabaseCreationRequest object. I went with keyword arguments instead, because every admin method in astrapy already follows that style and it keeps the change fully backward compatible and minimal. The payload is built so that additional future knobs (further feature flags, etc.) can be added the same way. Happy to refactor toward an explicit request/definition object if you'd prefer that direction — just let me know.

Scope is deliberately limited to database creation (the issue's core). Region discovery (find_available_regions is still region-type=vector) is left as a possible follow-up.

Test plan

• New unit tests in tests/base/unit/test_admin_create_database.py assert the exact DevOps payload for the default / non-vector / fully-specified cases, sync and async, against a mock DevOps API (pytest_httpserver) — no live Astra needed.
• make format passes (ruff check + ruff format + mypy strict, on both astrapy and tests).
• Existing test_admin_conversions / test_imports unit tests still pass.
• Admin integration suite (tests/admin) against a real Astra account — not run locally (requires credentials); worth a maintainer run since payload changes touch the live DevOps API.