fix(printer,highlighter): declare the dedent dependency

[luantaraschi]

Follow-up to the review I left on #2214, which declares dedent for the linter. Same defect, two more published packages. This PR does not touch the linter, so the two can land in either order.

Reproduced against the published packages, not the workspace. In an empty project, installing @herb-tools/printer@0.10.3 on its own and running its CLI:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'dedent' imported from
  node_modules/@herb-tools/printer/dist/cli.js

@herb-tools/highlighter@0.10.3 fails the same way from its own dist/cli.js. Installing dedent clears it. The workspace never sees this because the root package.json carries dedent as a devDependency, so it resolves for everyone developing in the monorepo and only breaks for people installing from npm.

Why these two and not the others. I unpacked the 0.10.3 tarballs and looked for an external dedent import in what actually ships:

package	import dedent in src/	external import in dist/	declared
printer	src/cli.ts	dist/cli.js:2	no, this PR
highlighter	src/cli.ts	dist/cli.js:1	no, this PR
linter	2 files	2 files	no, #2214
formatter	src/cli.ts, src/comment-helpers.ts	none, inlined into herb-format.js	not needed

The formatter is the interesting row. It imports dedent in src/ exactly like the others, but its build bundles everything into a single herb-format.js with dedent inlined at line 37, so it has no runtime dependency to declare. I confirmed that by running the published formatter CLI in the same empty project with no dedent installed: it prints its usage instead of failing. So the fix is two packages, not four.

Two more I deliberately left alone:

• vscode imports dedent in src/issue-reporter.ts, but the package is private: true and esbuild-bundled, so nothing is published and nothing breaks. A devDependency there would be tidier, not a fix.
• language-server declares dedent in dependencies but its only use is in a test file, so that one is in the wrong section rather than missing. I did not want to remove a dependency from a published package in a PR about adding them, but it is worth a look.

No lockfile change needed. yarn.lock already resolves dedent@^1.7.2, which is the exact range the root and the language-server use and the one added here, so yarn install --frozen-lockfile stays satisfied.

One thing I could not run. This repo does not check out on Windows: three fixtures under config/action_view_helpers/ have ? in their filenames, which NTFS rejects. I built the change through the git object store rather than a working tree, and I verified the two blobs I extracted hash-match the ones on main before editing them, so the diff is exactly the two lines you see. I did not run the test suite. Given the change is two dependency declarations that the lockfile already resolves, CI should be the honest word on it.

Unrelated, but you may want to know since I hit it: with dedent installed, @herb-tools/printer@0.10.3's CLI gets past that error and then fails with ERR_IMPORT_ATTRIBUTE_MISSING on a JSON import. Different bug, not touched here.