Refactor BackendSpecProvider to use Protocols to define the types it returns

[nschank]

What does this PR do ?

Some relevant discussion in #3434 - basically, BackendSpecProvider is accidentally obfuscating the types right now, stunting the effectiveness of the other Protocol updates. By having BackendSpecProvider actually specify the interfaces that must be honored by subclasses, the spec types all work together nicely.

Associated design doc: Typed ModuleSpec.pdf

Notes:

• Consistently using @overload and @final help ensure that the type checker will force the subclass to properly implement the interface.
• We still return 'specific types' in the subclasses so that callers can use additional information if they have it, but the type-checking of each BackendSpecProvider subclass ensures that the return types actually honor the interface that BackendSpecProvider specified.
• I got rid of the extra bool method, since you can just use an is None check (and that's easier to type check too).
• I added linear to all spec providers to make it consistent; since LocalSpecProvider didn't have one already I defaulted to NotYetImplemented.

Contribution process

Pre-checks

• I have added relevant unit tests
• I have added relevant functional tests
• I have added proper typing to my code Typing guidelines
• I have added relevant documentation
• I have run the autoformatter.sh on my PR

Code review

Feel free to message or comment the @mcore-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!

All PRs start as draft. If you open a non-draft PR, it will be automatically converted to draft.

Step 1: Mark PR as "Ready for Review"

1. When your PR is ready, click Ready for Review.
2. An oncall reviewer is auto-assigned and expert reviewers are notified based on your changes.
   • Some PRs may jump straight to step 2. This is determined by .github/CODEOWNERS.

⚠️ Only mark as ready once merge-conflicts are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

Step 2: Final Review

For PRs that change megatron/core, once all expert reviewers have approved, the Final Review label is applied automatically and final reviewers are assigned.

For PRs outside megatron/core, this step is skipped.

Step 3: Approved

Once all required reviewers have approved, the Approved label is applied automatically.

Merge

Any member of mcore-engineers will be able to merge your PR.

For MRs into `dev` branch

The proposed review process for `dev` branch is under active discussion.

MRs are mergable after one approval by either eharper@nvidia.com or zijiey@nvidia.com.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.