…azelbuild#2879)"

This reverts commit f92f668.

…2879)" (#2906)

# Background

This reverts commit f92f668.

solves #2901

This issue is a regression introduced by
#2879, which added support
for multiple dependencies for app_intents.

The approach was as follows:

1. Parse each dependency module
2. Merge the generated metadata into a single dummy module's metadata
using the `--static-metadata-file-list` option of
`appintentmetadataprocessor`, which is intended to propagate dependency
metadata (definition of `AppIntents`) to dependents
3. Bundle the result of step 2 into the app

However, it turns out that `--static-metadata-file-list` does not
propagate AppShortcutsProvider to dependent modules. In other words, the
processor only recognizes providers defined in the last (root) module it
processes.

Since the root module in this approach is a dummy module, providers
defined in modules passed to `app_intents` are dropped during step 2.

# Approach

Let me revert it now and start over thinking about proper approach.

Now I’m thinking it would be better to keep the single-module
restriction for the app_intents argument. Since the processor
essentially expects a single root module for defining
`AppShortcutsProvider`, it makes sense for app_intents to specify that
root module.

Instead, it would be more appropriate to support recursively parsing the
metadata of dependency modules from the module passed to app_intents,
which would effectively allow handling multiple modules. I might try to
work on it when I have a time

any other idea, suggestion are welcomed

BTW, I'm going to open an another PR for adding test cases regarding
`AppShortcutsProvider`, it helps us avoiding such regression in the
future.

I'm sorry for causing this problem and thanks for reviewers,
contributors support 🙇