[core] Replace Jasmine v1 Test Runner with new repo

[confused-Techie]

As discussed on Discord, this PR replaces all of our existing jasmine1-test-runner logic with my working repository pulsar-jasmine1-test-runner.

Doing this brings quite a bit of code (that we likely will never touch due to compatibility) out of core and siloed into it's own repo.

Why do this?

Currently, our Jasmine 1 test runner, is honestly wildly complex. And if you wanted to track down how it all worked, boy were you in for a bad time.

Without getting too into the weeds of it, but to truly understand how we defined Jasmine, you'd have to:

• ./spec/helpers: Has several different modules that add new stuff or change stuff of Jasmine
• ./vendor/jasmine.js: Seems like it'd be our main jasmine definition, but it's actually mostly redefined later.
• ./vendor/jquery-jasmine.js: More special stuff on top of Jasmine
• jasmine-focused: Another repository that does more special stuff
• jasmine-json: Another repository that does more special stuff
• jasmine-reporters: Another repository that does more special stuff
• jasmine-tagged: Another repository that does more special stuff
• jasmine-node: Now it gets tricky, this isn't mheverys repository like you might think, it's a branched version made by kevinsawicki that we technically import from jasmine-focused that we define over itself a couple of times. Even more complicated we technically define it over top of our own vendored Jasmine, but the two copies are nearly identical, except about 18 additions by kevinsawicki and about 276 additions on our vendored copy.

And keep in mind with how much redefining we do over top of things already defined in the global namespace the order of these changes/redefinitions matters a great deal.

Plus each new repository has many of the same modules of varying versions that are all out of sync with each other.

---

So to finally answer the why, bringing in a single module of pulsar-jasmine1-test-runner means we can archive all of these separate repos, and have one set of modules to keep updated within this other repository, and means we can put all of the code that defines our jasmine1 runner in one place.

Even though in that repo I kept the structure the same, meaning there's still a lot of bouncing back and forth, and redefinitions, I still feel the advantages outweigh the disadvantages. Especially when we consider that we will likely never change how this test runner functions, we would only move to update the test runner like we already have with our jasmine2-test-runner being what's used in the main Pulsar repository.

---

Now I will specify, if we like what this PR does and the general shape of my working example of the pulsar-jasmine1-test-runner repository, I'd recommend that prior to any kind of merge we fork my repo to Pulsar, and publish to NPM as @pulsar-edit/jasmine1-test-runner then make sure we use that version here. Just getting this up as a way to get this idea reviewed in some detail.

And if we don't like the shape of my repository I'm already having to stop myself from trying to clean it up too much, since while I'd want to, I would be pretty nervous about breaking something in a subtle hard to catch way, but I'd still be up for cleaning it up if we really wanted too

[savetheclocktower]

Adding myself as a reviewer so that I don't forget about this. Also gave it a 1.134.0 milestone so that it gets reviewed eventually (we've already got a lot of stuff in the hopper for 1.133.0!).

[savetheclocktower]

I'll try to give this proper review tonight.

But in the meantime: this is clearly the direction in which we want to go, so feel free to transfer pulsar-jasmine1-test-runner to the pulsar-edit organization. (Maybe it can be renamed jasmine1-test-runner to reduce verbosity, since the org name will clarify the context?)

My dream is to have this and Jasmine 2 (the status quo for Pulsar's own non-package specs and one or two core packages) and Jasmine 5 be available as modular runners like this. I am not certain whether a community package would be able to specify the runner by package name and have it recognize the runner's ambient availability — that needs research. But if not, I figured we could have some sort of magic syntax that means “use this specific runner that I know to be bundled with Pulsar” — like atomTestRunner: "$pulsar/jasmine-1-runner" or something like that.

[savetheclocktower]

So this appears to work great, but there are a couple of snags:

1. Let's definitely get the repo transferred over to pulsar-edit and publish it; then we can update the reference here.
2. The graphical runner is broken because of a require of a nonexistent path; see here.

One other issue that Claude caught and which I consider minor: We create a TextEditor in the spec window in order to capture references to TextMateLanguageMode and TextEditorElement, but then we never destroy the editor. This is pretty minor, since it's a leak of only one editor per run.