Respect importModuleSpecifierPreference in sort order between fixes for the same symbol from different files

[andrewbranch]

Fixes #55863

There were two bugs in play:

1. importModuleSpecifierPreference was only being considered in how to generate module specifiers between a given pair of files. But when computing auto-imports, there may be multiple files a missing symbol can be imported from, so the module specifier generation code is called multiple times, and multiple fixes are generated. Those fixes are then sorted, but the sort logic didn’t consider importModuleSpecifierPreference. In most cases, all the generated fixes either successfully satisfied the preference or didn’t, but it’s possible, as in the bug repro and test case, that e.g. the symbol being imported is available from one file that can only be reached by relative path and another file that can be reached by a non-relative paths/baseUrl module specifier.
2. In the import fix sorting, we also sort by whether the module specifier for the fix is a listed package.json dependency whenever that specifier is non-relative. But a non-relative specifier may be a node_modules package, or it may be generated from paths/baseUrl. We were incorrectly checking whether these paths/baseUrl specifiers were package.json dependencies, which would further deprioritize them under relative paths. (Writing this out makes me realize that I need to follow up with a separate test to ensure that package.json imports and self-name imports are not being deprioritized for the same reason.)

[andrewbranch]

It always should have been in this order due to number of path segments, but #is-browser was being demoted because it was being checked against package.json dependencies, as I mentioned in the PR description.