fix: pass resource aliases to file-level CommonResources

[ohmayr]

File-level resources (like imported dependencies) were previously starved of CLI aliases during dummy MessageType creation. This caused false-positive namespace collisions because the collision checker couldn't see the explicit aliases.

This wires opts.resource_name_aliases down through api.py into CommonResource.build() so the alias resolution works as originally intended.

Fixes: #16952

[gemini-code-assist]

Code Review

This pull request adds support for resource name aliases by introducing a resource_name_aliases field to the Proto and CommonResource classes and ensuring its propagation throughout the schema generation process. A review comment identifies a potential debug leftover in an error message within wrappers.py where a raw dictionary is printed, suggesting its removal to ensure the output remains clean and user-friendly.

[gemini-code-assist]

The inclusion of {seen_types} in the error message appears to be a debug leftover. Printing a raw dictionary of objects in a user-facing error message is generally not recommended as it can be very verbose and difficult to read. If you intended to provide more context about the collision, consider formatting the output to only show the relevant conflicting types.

                    f"To protect backward compatibility, explicitly alias one of these using "
                    f"the --resource-name-alias CLI parameter.\\n"
                    f"Example: --resource-name-alias={msg.resource_type_full_path}:CustomName\\n"
                )