Decouple test lifecycle from Crystal Spec to support minitest.cr (and other test frameworks)

[papilip]

Context

Marten::Spec provides excellent test helpers (client, delivered_emails, DB flush, etc.) but is currently hard-wired to Crystal's built-in Spec framework. The lifecycle is registered in src/marten/spec.cr via:

Spec.before_suite &->Marten.setup
Spec.before_suite &->Marten::Spec.setup_databases
Spec.after_each  &->Marten::Spec.flush_databases
Spec.after_each  &->Marten::Spec.clear_collected_emails
Spec.after_each  &->Marten::Spec.clear_client
Spec.after_each  &->DB::Statement.reset_query_count

This means Marten apps cannot currently be tested with alternative Crystal test frameworks such as minitest.cr or spectator without losing DB/client/email reset between tests — minitest.cr is a standalone runner with its own lifecycle (before_setup/after_teardown/Minitest.after_run) and does not trigger Crystal Spec's callbacks.

This came up while documenting Marten for Rails developers (see #357), where Minitest is one of two canonical Ruby test frameworks — readers naturally expect a Crystal Minitest port to "just work".

Proposal

Split Marten::Spec into two layers:

1. Marten::Testing::Lifecycle (new, framework-agnostic)
   Pure module containing setup_databases, flush_databases, clear_client, clear_collected_emails, client, delivered_emails. No require "spec", no callback registration.

2. Marten::Spec (existing, becomes a thin Crystal Spec adapter)
   Keeps the current public API by re-exporting from Marten::Testing::Lifecycle, and is the file that require "spec" plus registers the 6 hooks above. No breaking change for current users.

This unblocks community-maintained adapters such as marten-minitest or marten-spectator without forcing Marten to take on extra dependencies.

Open questions for maintainers

• Scope: should the refactor land alone (option A), or should an official src/marten/minitest.cr adapter ship alongside it (option B)? Option A keeps Marten's dependency graph unchanged and lets adapters live in separate shards.
• Naming: Marten::Testing::Lifecycle, Marten::Test, or another module path?
• Backwards compatibility: confirm that the public API (Marten::Spec.client, Marten::Spec.delivered_emails, the Marten::Spec::Client type) must remain stable.

Happy to submit a PR for option A once direction is confirmed.