[Feature]: `dts.only`

What problem does this feature solve?

https://github.com/web-infra-dev/rspress/blob/d7513e0340a7135c4136e87f154fbe792be447d1/packages/plugin-algolia/rslib.config.ts#L8

before

I have three tasks 1. bundle-node 2. bundle-web 3. bundleless-dts, but i have to define 3 tasks into 2

export default defineConfig({
  lib: [
    {
      source: {
        entry: {
          index: './src/index.ts',
        },
      },
      dts: true,  // <--------- in this line
      format: 'esm',
      syntax: 'esnext',
    },
    {
      source: {
        entry: {
          index: './src/runtime/index.ts',
        },
      },
      format: 'esm',
      syntax: 'esnext',
      plugins: [pluginReact()],
      output: {
        externals: [
          '@theme',
          'react',
          'react/jsx-runtime',
          'react/jsx-dev-runtime',
        ],
        target: 'web',
      },
    },
  ],
});

after

lib: [
  // js only
  {
     source: {
        entry: ''
     }
  },
  // js only 2
  {
     source: {
        entry: ''
     }
  },
 // dts only
  {
     dts: {
       only: true
      }
  }
]

What does the proposed API look like?

https://modernjs.dev/module-tools/api/config/build-config.html#dtsonly

Some drawbacks

We suggest that esm and cjs each have their own dts files, but in this way, we can share the same dts files for both esm and cjs.

This is actually a misuse, which is easy to lead users to incorrect usage.

Review the example configuration in packages/plugin-algolia/rslib.config.ts and compare the proposed dts.only API with the linked Modern.js documentation. Determine how the configuration should represent JavaScript-only and declaration-only tasks, then verify that the resulting build setup supports the stated shared-d.ts use case and its documented drawbacks.