docs: add platform-specific implementation and helpers

[SkyZeroZx]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.dev application / infrastructure changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[alan-agius4]

I am a bit hesitant to include details on isPlatformBrowser and isPlatformServer in the SSR guide. Historically, these have been considered an escape hatch, and developers should be not be relying on them heavily. A better, more idiomatic approach is to use DI to provide platform-specific implementations.

Furthermore, we must first document the recommended practices for overriding providers within the SSR documentation, as this is the preferred method that developers should follow.

[SkyZeroZx]

I am a bit hesitant to include details on isPlatformBrowser and isPlatformServer in the SSR guide. Historically, these have been considered an escape hatch, and developers should be not be relying on them heavily. A better, more idiomatic approach is to use DI to provide platform-specific implementations.

Furthermore, we must first document the recommended practices for overriding providers within the SSR documentation, as this is the preferred method that developers should follow.

So to include this section, we should first add one about providing platform-specific implementations, and then introduce the section about the helpers.

While platform-specific implementations are generally preferred, I also think the helpers are necessary as a workaround when dealing with third-party libraries.

[JeanMeche]

I've also chatted a bit with @thePunderWoman when you opened #64846. The idea is that those helpers are mostely not recommended and should be last resort solution (or escape hatch liek Alan is saying).

What we should be documenting are the alternatives (distinct providers, browser only apis life afterNextRender/afterRenderEffect etc. )

[SkyZeroZx]

Updated with the recommendations, a section "Providing platform-specific implementations" has been added and the previously added section has been retained; a note has also been added indicating which option is recommended.