✨(testinit): add a simple (interactive?) cli that creates a new test module skeleton

[danceratopz]

Add a new command, for example, testinit that creates a new python test module at the specified path for the specified:

• native test format (state_test/state_test_only, blockchain_test/blockchain_test_engine, eof_test),
• valid from fork.

It should create a new test module at the specified path (creating directories if necessary) that contains:

1. The necessary imports to start implementing the test (we'll have to see how many import it makes sense to include by default).
2. A test function with:
   a. Appropriate test fixtures in its function args, e.g., def <same_as_module_name>(state_test: StateTestFiller, pre: Alloc):
   b. A @pytest.mark.valid_from() decorator on the test function with the fork specified by the user.
   c. A test body that calls the test spec type, e.g. state_test()
   d. It should be typehinted.

It would be very cool if fill could run on this output and generate a fixture, even if most of it is empty/minimal. We'll have to see if this makes sense.

If this was a "static" CLI, it would look something like:

uv run testinit <test-format> <valid-from> <target-output-file>

For example:

uv run testinit state_test Prague tests/prague/eip7742_uncouple-blobs/test_uncouple_blobs.py

But perhaps, as we may want to add different "flavors" of test types, e.g.,:

• parametrized vs non-parametrized, or
• regular blockchain_test or a transition blockchain_test,
  it may be worth exploring an interactive CLI upfront that guides the user through which type of test to add. Something like questionary could help here. InquirerPy seems like another helpful, but less popular, option. We already have rich as a dependency, perhaps that influences the decision (the rich author has also created Textual, but it seems like overkill for our use case).

This command could be a new entry-point that directly hooks into the new gentest architecture, see #901.