metro-file-map: Let plugins report what changed in a batch, on the change event

[robhogan]

Context

A file map plugin often knows things about a batch of changes that nothing else can work out. For Haste, #1952 records the names a resolution looked up, and invalidating from those means knowing which names a change rebound. The ChangeEvent carries paths, and by the time a consumer sees it a removed file's name is already gone from the map, but HastePlugin.onChanged has it to hand:

metro/packages/metro-file-map/src/plugins/HastePlugin.js

Lines 241 to 245 in 6dbe979

	onChanged(delta: ReadonlyFileSystemChanges<?string>): void {
	// Process removals first so that moves aren't treated as duplicates.
	for (const [canonicalPath, maybeHasteId] of delta.removedFiles) {
	this.#onRemovedFile(canonicalPath, maybeHasteId);
	}

This change

This lets a plugin's onChanged return a summary, published on ChangeEvent.pluginChanges by plugin name. The summary type defaults to void, so existing plugins are unaffected. HastePlugin reports changedNames.

Plugin names now have to be unique across all plugins, not just those with a worker. Persisted state was already keyed by name, so two sharing a name were already overwriting each other.

Not addressed here: on a cold start HastePlugin builds a summary nobody reads (transient, and nothing where Haste is inert), and an edit that changes a file's Haste name is neither applied to the map nor reported, which predates this.

Invalidating from the summary is the next PR.

Changelog: Internal

Test plan

New unit tests cover the watch and recrawl paths and duplicate plugin names.