Add CARTA startup version validation

[izkgao]

Description

Closes #166 and #28.

Companion frontend PRs: CARTAvis/carta-frontend#2921

Prepare the carta-python 2.0 development cycle. This branch adds data-driven CARTA compatibility validation, validates CARTA 6.1+ during session startup, and documents the updated PyPI and development workflow.

What is implemented:

• Add startup CARTA version validation with configurable warning/error handling, compatibility suggestions, improved action errors, and backend cleanup when session creation fails.
• Start 2.0.0-dev, rename the distribution to carta-python, and add the data-driven compatibility table/version helpers.
• Update installation, quickstart, and development documentation, with tests covering session validation, compatibility behavior, error paths, and deprecation handling.
• Add PR template

Checklist

For linked issues (if any):

• assignee and labels added
• GitHub Project estimate added

For the pull request:

• reviewers and assignee added
• GitHub Project estimate added
• tests added or updated / no tests needed
• documentation updated / no documentation update needed

For dependencies and compatibility:

• companion frontend or backend PRs linked / no companion PRs needed
• pyproject.toml and uv.lock updated / no dependency changes
• CARTA compatibility table updated when the minimum CARTA series changes
  or dev starts a new carta-python major/minor series / no compatibility
  change

For pull requests targeting main:

• VERSION.txt finalized for the release
• final compatibility entry matches the release major/minor version and
  minimum supported CARTA series

[izkgao]

I'll update the PR to implement this now.

Before bumping the wrapper version, should we create the main branch and use it as the source for Read the Docs, so that the documentation won't be affected by ongoing development?

Also, for the first beta release, would we prefer to start with 2.0.0 or 1.3.0?

[izkgao]

Previously, I thought we should limit support to a single CARTA major version, since deprecated frontend APIs could be removed in the next major release. However, now that we have decided carta-python should support multiple frontend API versions, this restriction no longer seems necessary.

Because CARTA typically has only a few minor releases within each major version, it makes more sense for a carta-python release to remain compatible with future CARTA versions until an actual breaking change occurs. I also plan to add frontend CI checks to detect such breaking changes.

I have updated the code and documentation accordingly.