Rework search path discovery and processing

[jakebailey]

The search path code (and potentially Interpreter itself) could use a rework. Motivations:

• Search path management occurs in multiple places, rather than one:
  • Server.InitializeAsync - this only processes searchPaths given in the initialization options, and does quite a bit of work removing and deduplicating items. Some of this is fine, but this is also the place where the Interpreter instance is created for the first time.
  • MainModuleResolution.ReloadAsync - This actually calls out to the interpreter and gets what it considers to be the search paths. Then, things are swapped back and forth between that path list.
• extraPaths becomes required for editable installs. This is due to the fact that an editable install uses a pth file to modify the interpreter paths, which we then read out and consider to be library code. Only extraPaths can move those paths back out to be user code again.
  • Perhaps some basic pth file support would be useful, specifically something that would only handle editable installs (to start).
• The two places means that only the latter (ReloadAsync) is actually executed when something changes; this prevents user configuration from being changed on the fly, and potentially coming out of sync if a package is installed as editable without a reload.
• There are multiple places where an interpreter gets its paths modified and filtered then placed back, which is weird.

Likely other things, which I'll edit in as I remember them.