[FEATURE] Warn about tags TER already implies

[CybotTM]

Resolves #96, along the lines @bmack agreed to there: warning plus README update.

The rule

Every extension in TER is a TYPO3 extension, so typo3, typo3-extension, extension, cms and php narrow nothing down there. The same terms are what make a package findable on GitHub or Packagist — which is exactly why a publishing pipeline that reuses one vocabulary across registries sends them to TER.

Measured, not assumed

I first wrote the term list from that reasoning alone. Checking it against 3000 TER extensions and the three vocabularies of the top 60 by downloads changed it:

Vocabulary	Platform terms	Share
TER tags (625 occurrences)	5	0.8%
composer.json keywords (207)	46	22%
GitHub topics (92)	~50	54%

Two things follow. TER tags are largely clean today — the top terms are content, backend, responsive, news, typoscript — so this is preventive rather than a fix for a widespread mess. And the sources a pipeline would copy from are anything but clean, so the warning earns its place the moment tags are automated.

The measurement also corrected the list: composer.json keywords favour typo3 cms with a space (the second most common keyword overall) and GitHub topics favour typo3-cms-extension — neither was in my first draft. Rather than enumerate permutations, terms are now compared with separators stripped, so those variants and future ones collapse to one entry. Domain tags that legitimately contain separators (e-commerce, tt_news) are unaffected, and a test pins that down.

Worth noting alongside: only 134 of 3000 sampled extensions use tags at all.

Warning, not filter

 [WARNING] Every extension in TER is a TYPO3 extension, so typo3, php add no
           discoverability there. Consider tags describing what the extension
           does instead.

The request goes out unchanged. Tailor is a thin client over PUT /extension/{key}; dropping a value someone passed explicitly would be surprising, and which terms count as too generic is a judgement for the caller.

Discoverable before the run, not only after

A runtime warning arrives once a pipeline has been written and executed. The rule is therefore also in the --tags description, which is what ter:update -h prints and what someone — or a coding agent — reads while writing that pipeline:

--tags[=TAGS]   Comma-separated list of tags. Replaces the existing list. Every
                extension in TER is a TYPO3 extension, so terms like typo3,
                typo3-extension, extension or php add no discoverability there -
                prefer tags describing what the extension does.

The README section gains the same reasoning and connects it to the replace semantics documented just below it — that combination is what bites automated publishing, since every release overwrites curated tags.

Implementation

Matching lives in CommandHelper::getTagsImpliedByTer() so it is unit-tested rather than buried in the command: case-insensitive, separator-insensitive, tolerant of whitespace and empty segments, and no substring matches.

composer cs clean, composer tests:unit green — 67 tests, 183 assertions, 11 of them new.

[CybotTM]

Heads-up while reviewing: I filed #98 after trying to use --tags for real. It stores only the first comma-separated element and reports failure while doing so, so the README example --tags=some-tag,another-tag currently sets one tag and returns a non-zero exit.

That does not invalidate this PR — the guidance is about which tags to choose and stays correct — but the two are worth reading together, and the README wording here may want a pointer once #98 is resolved. Happy to fold a note in if you prefer.