Add validation that the extension name matches the package name

[johnpryan]

This ensures that packages can't provide extensions for package with a different name.

To test this behavior, create a new package under packages/devtools_extensions/example/test_validation_pkg:

devtools/config.yaml:

name: provider
issueTracker: https://github.com/flutter/devtools/issues
version: 1.0.0
materialIconCodePoint: "0xe50a"
requiresConnection: false

pubspec.yaml:

name: bad_pkg
description: A test package for manually validating DevTools extension configs.
version: 1.0.0

environment:
  sdk: ^3.11.0

Run the validator:

dart run devtools_extensions validate -p example/test_validation_pkg

Validation error: The "name" field in config.yaml (TEST_VALIDATION_PKG) does not match the package name in pubspec.yaml (test_validation_pkg).

[gemini-code-assist]

Code Review

This pull request introduces validation during DevTools extension discovery and validation to ensure that an extension's declared name in config.yaml matches its containing package name. If there is a mismatch, the extension is ignored (with a warning) or validation fails. This is implemented across devtools_shared and devtools_extensions, with corresponding tests added.

Feedback on the changes highlights two potential runtime issues:

1. In extension_manager.dart, if the name field in config.yaml is missing or not a string, the extension will be silently ignored with a mismatch warning instead of throwing a more descriptive parsing error. It is suggested to only perform the mismatch check if extensionName is a String.
2. In _validate.dart, casting pubspecYaml['name'] and configYaml['name'] directly using as String? can cause a runtime TypeError if the fields are parsed as non-string types. Safe type checking should be used instead.

[kenzieschmoll]

The actually breaks an intentional feature of DevTools extensions that allows you to develop your extension in a different package than the one where you ship it. See https://github.com/rrousselGit/provider/tree/master/packages for an example. This is necessary because many package authors want to decouple their Flutter Web project (DevTools extension) from their package that users import as a direct dependency. Developing the devtools extension in another package allows the Flutter web code and deps to be kept separate from the package users depend on.

[johnpryan]

I didn't realize that was the intended behavior. I'm not sure how exactly to proceed. Here here are some alternatives we could consider:

1. Allow the devtools name to match the package name foo OR foo_devtools_extension. That way a package likebad_pkg can't claim to be foo. This isn't great because this would still mean that someone could publish foo_devtools_extension, even if they didn't own foo.
2. Improve the deduplication logic, so that if package:foo and package:bad_package both claim to provide the foo devtools extension in the same workspace, we choose to use the correct version (although I'm not exactly sure how to determine this if there's no strong association between the extension package and the parent package)