Deprecate `@CsvSource.textBlock` in favour of `.value[]`

[mpkorstanje]

Since #4339 it is possible to use @CsvSource.value[] with text blocks. We want to deprecate @CsvSource.textBlock for removal so there's a single option: value which can be used with a text blocks or regular strings. Functionally value[] and textBlock are not identical. textBlock skips comment lines while value[] rejects these (after #5886). So enabling comments for value[] is safe provided users first upgrade to the latest v6.x.

Deliverables

• Allow comments in @CsvSource.value[]
• Deprecate @CsvSource.textBlockfor removal
• Update our docs to use value[] instead of textBlock
• Update our tests to use value[] instead of textBlock (except textBlock tests).
• Document in the migration guide that users should upgrade to the latest v6.x before upgrading to v7.

[oaksprout]

Would you want this one done? — JUnit should allow comment lines in @CsvSource's value array now that comment-rejection has landed, then deprecate @CsvSource.textBlock for removal in favor of value, updating the docs, tests, and migration guide to match. If yes, we'll do it and open a PR; if not, say so (or just ignore this) and we won't touch it.

How it works: an AI agent does the work against your write-up. Before anything reaches you, the change is rebuilt and tested from a clean copy of your project, using your own test suite, and the results are kept in a record you can check yourself. A human reviews it, submits it, and answers the review. You keep full control — nothing lands unless you merge it.

We're testing whether work offered this way is useful to maintainers — a blunt "no" is as helpful as a yes.