[plugin_platform_interface] Fix broken link for federated-plugin

[wer-mathurin]

Description

Fix broken link for federated-plugin

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.

• My PR includes unit or integration tests for all changed/updated/fixed behaviors (See [Contributor Guide]).
  This is not changing the code itself, just the readme

• All existing and new tests are passing.

• I updated/added relevant documentation (doc comments with ///).

• The analyzer (flutter analyze) does not report any problems on my PR.

• I read and followed the [Flutter Style Guide].

• The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]

• I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy].

• I updated CHANGELOG.md to add a description of the change.

• I signed the [CLA].

• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
• No, this is not a breaking change.

[stuartmorgan-g]

Thanks for the submission! We apologize for the long delay in triaging this PR. We’re in the process of overhauling our PR triage system to respond much more quickly, as well as working through the backlog.

Unfortunately we ended up with a duplicate PR in #4143, which has now landed, so closing this as obsolete.

[wer-mathurin]

@stuartmorgan not a problem, the most important thing is that it finally updated!

But....

If I can make a suggestion.
They idea is that the experience/adoption with Flutter and library around it will improve with better documentation. Having a stale/broken documentation for 6 months, it's a shame from my perspective.(maybe shame is a strong word...let say not a good idea)

I don't like only complaining, so here what I propose to make potentially that kind of PR going through more rapidly.
I don't know the process behind who look at it and what are the picking up process of PR, so throwing a guess of solution!

Adding a checkbox or kind of labeling that is saying, ONLY UPDATING THE README or ONLY UPDATING THE DOCUMENTATION
From my perspective this is different since, the documentation can be in the code, so you need to validate it does not break the code and follow best practices(lints), but the readme can be simple to validate from my perspective.

From there this can be an easy process to validate the PR.

Cheers

[stuartmorgan-g]

As I said above: "We’re in the process of overhauling our PR triage system to respond much more quickly". New PRs are now triaged within two weeks; usually within one.

The problem before isn't that people weren't able to tell whether a PR was only updating a README during triage, it's that triage wasn't being consistently done on all incoming PRs.