Standardize on index.ts entry points

[josemontespg]

Standardize on index.ts entry points.

What

• Rename public_api.ts style entry point files to index.ts across Angular packages.
• Update references in configuration files (package.json, tsconfig.json, etc.).
• Update renderers/angular/src/index.ts to explicitly export v0_8/index instead of v0_8.

Why

• Align with standard module resolution practices.
• Address reviewer feedback to explicitly export /index to ensure robust resolution in strict ESM environments.
• Tracked in b/535315569.

Effect

• Standardized entry points simplify import structures and build configurations.
• Explicit /index export prevents potential resolution failures.

Testing

• Verified by running build/tests.

[gemini-code-assist]

Code Review

This pull request standardizes the entry point configuration across several Angular packages and samples by transitioning from public-api.ts to index.ts. Feedback on these changes suggests explicitly appending /index to the export statement in renderers/angular/src/index.ts to ensure robust module resolution and avoid potential failures in strict ESM environments or specific bundler configurations.

[josemontespg]

Keep the public_api.ts files for backwards compatibility. Apps might be importing directly from public_api.ts and we don't want those imports to break.

You may keep lean public_api.ts files that just reexport everything from index.ts, with a comment saying that the public_api.ts file is there for the purpose of backwards compatibility.

[josemontespg]

Are there any public_api.ts files to refactor in web_core or other web adapters, like lit and react? Apply the refactor in those as well.

[josemontespg]

Regarding keeping public_api.ts for backwards compatibility: I have confirmed that the public-api.ts files have been restored as backwards compatibility wrappers that re-export index.ts.

[josemontespg]

Regarding refactoring public_api.ts in other web adapters: I have searched for public-api.ts or public_api.ts files in web_core and lit packages and confirmed that there are none, so no refactoring was needed there.