Drop support for `kamel run --dev/--sync`

[squakez]

Requirement

They were deprecated already in v2.9.0 so we can safely remove.

[Suhail98]

I'd like to take this one.

--dev and --sync are only wired into kamel run, so the removal is contained to pkg/cmd/run.go plus the code that exists solely to serve them:

• the two flag registrations and the Sync / Dev fields on runCmdOptions
• the --dev + -o mutual-exclusion check and the "Dev and Sync properties are deprecated" notice in validate
• in run: the SIGTERM handler that deletes the Integration on Ctrl-C, the syncIntegration call, and the o.Dev / o.Sync arms of the --logs / --wait conditions — --logs and --wait keep their current behaviour untouched
• syncIntegration itself, and what only it uses: filterFileLocation in run_support.go, the pkg/util/sync package, and DeleteIntegration in pkg/cmd/util.go (the e2e suite has its own DeleteIntegrations, so nothing else calls it)

Two notes on judgement calls, both taken from your review of #6807 and #6816:

• I'm not adding a test asserting the flags are gone — you've said twice that the absence of the logic is the proof.
• Cobra already rejects an unknown flag with unknown flag: --dev, so no deprecation shim or extra warning is needed; --dev behaves like any other typo.

Docs are almost untouched: the only mention left in docs/ is a passing "dev mode" aside in configuration/dependencies.adoc, which I'll reword rather than delete, since the point it makes about automatic dependency resolution still stands.

One question worth your call: pkg/util/sync is an exported package, so deleting it is technically breaking for anyone importing it. Based on your answer on #6807 about TemplateResource() I'm assuming the same applies here and removing it is preferred over leaving it dead — say the word if you'd rather I keep it.

PR on the way.

[squakez]

One question worth your call: pkg/util/sync is an exported package, so deleting it is technically breaking for anyone importing it. Based on your answer on #6807 about TemplateResource() I'm assuming the same applies here and removing it is preferred over leaving it dead — say the word if you'd rather I keep it.

Yeah, we don't really expect the logic to be used externally, so, no reason to keep the code and we can clean it.