Core: StorybookConfig stories-field support type async function

[imccausl]

Closes #21524

What I did

Modifies to the StorybookConfig['stories'] type to include a function that returns a Promise that resolves to StoriesEntry[]. This should cover the custom implementation case. Since this logic is already supported where presets are loaded/resolved and is already documented, I did not make changes to documentation or add tests.

How to test

1. modify main.ts in ui/.storybook so that the stories key in the config has an async function that resolves a promise like this:

const asyncStories = Promise.resolve(allStories)
const config: StorybookConfig = {
     stories: async () => [... (await asyncStories)],
     // ...rest of the config

2. After this modification you should not see a typescript error on the stories key regardless of how you configure stories (async func or as a StoriesEntry array.
3. run yarn start to run the storybook dev server
4. all stories should load as expected.

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 (updated docstring)
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Maintainers

• If this PR should be tested against many or all sandboxes,
  make sure to add the ci:merged or ci:daily GH label to it.
• Make sure this PR contains one of the labels below.

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

[ndelangen]

@shilman I think we need to discuss this...

Perhaps we decide after GA?

This PR seems correct to me..

• we have documentation saying it should be so
• we have implementation saying it should be so

Yet our types say not.

We kinda want to have this just be an array, because this value can be modified by codemods (maybe?), and for those to work, we want it to be a simple value.

But considering the above, I think we should merge this as-is, make the types match the documentation & implementation, then figure out how to do better config in the future.
I suspect we'll just have to make codemods smarter/better to cope with this.