Addon-docs: Fix Table of Contents heading leak

[vmizg]

Closes #23541

What I did

Exclude all content from Story blocks from being indexed by the Table of Contents (TOC) component by default. The user can still override the ignoreSelector to adjust this behaviour.

IMO, the default headingSelector should be h2, h3 instead of just h3, but this is not in the scope of this fix. Worth considering?

How to test

1. Set up the following TOC config in the sandbox/.storybook/preview.ts file:

   import type { Preview } from '@storybook/react';
   
   const preview: Preview = {
     parameters: {
       ...
       docs: {
         toc: {
           disable: false,
           headingSelector: 'h1, h2, h3',
         },
       },
     },
   };
   
   export default preview;
2. Run the default sandbox, yarn start
3. Open Storybook in your browser
4. Go to the Header Docs page
5. See that the Acme headings from the sample component do not bleed into the generated Table of Contents

To test the previous behaviour, do the same thing and note the difference in Table of Contents.

Checklist

• Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
• Make sure to add/update documentation regarding your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD (N/A)

Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts
• Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "build", "documentation", "maintenance", "dependencies", "other"]

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

[kylegach]

@shilman — This approach seems sound to me, but you're the one who left the commented-out version to seemingly accomplish the same thing, so thought you'd like to chime in.

[JReinhold]

Looks great, thanks!

[cdedreuille]

What's the status on this one @JReinhold @shilman? Any reason why this is not merged?