Refactor/extract scripting api 2

[guyguy2001]

Summary

This is part of the process of extracting the script-facing API from PoseEditMode in order to make it usable for non-booster scripts.
Replaces #749

Implementation Notes

I did it like the previous PR, except I didn't implement get_folder/select_folder, since they are behind a "lock", and I didn't want to think yet of whether or not I want the extracted logic to inherit the lock.
However, while get_folder is locked, the calculation functions (such as fold) which also access the folder, aren't locked (even on dev). Is this intended?

Testing

I ran https://eternagame.org/scripts/13774466, and it passed.
The script checks that all of the extracted functions (expect folding with binding sites) work and return the same values.

This is an unrelated issue, but : For some reason, both on main/master (https://eternagame.org/puzzles/6096060/play) and on my branch, the first time I run it I get the following errors, and on future runs it passes. Reloading the page makes the issue appear again for a single execution.
Errors:

Successful run:

(In my branch I just copy pasted the script, since I didn't have it on eternadev.org, and changed Lib.fold->applet.fold. I shouldn't have Lib in the terminal, right?)

Related Issues

Enables eternagame/eternagame.org#378, #750

[guyguy2001]

See my thoughts in #749 for bikeshedding and such

[luxaritas]

Overall, this looks good. Gut feeling says its a bit weird to construct a singleton that is implicitly dereferenced like this, but I understand why you did it. It might be nice if FoldingApi could be something you could use directly as an ExternalInterfaceCtx so that it actually becomes a domain object being passed around, but that comes with its own issues (now having to deal with multiple constraint contexts for the script interface or adding support for combining multiple contexts, having some method of exposing class methods and assigning them a name, etc). This is probably fine.

However, while get_folder is locked, the calculation functions (such as fold) which also access the folder, aren't locked (even on dev). Is this intended?

To be honest I think I forgot about that when I implemented it. That being said, I don't think current_folder (the name of the method that gets the current folder) would actually be subject to any race condition - setting the folder happens synchronously, it's the re-folding that's async. So that lock can probably be removed.

This is an unrelated issue, but : For some reason, both on main/master (https://eternagame.org/puzzles/6096060/play) and on my branch, the first time I run it I get the following errors, and on future runs it passes. Reloading the page makes the issue appear again for a single execution.

That is super bizarre. I think that flew under the radar previously because we didn't fully validate secondary structures until recently. My bet is that there's some improper c string dereferencing going on in our nupack cofold bindings. I can't place what the problem is on an initial look though

[guyguy2001]

Gut feeling says its a bit weird to construct a singleton that is implicitly dereferenced like this, but I understand why you did it.
What do you mean by that? The fact that I create an object and only use it to call a function?

If so, I was considering making it a function, but a class made more sense to my pythonic head, and it gives a nice (?) split between what things we get in the constructor for later use, and what we're registering onto.

Creating a foldingAPI object that will be called as maingame.api.folding.fold() might also be nice, but given that changing the folding engine is something that is only sometimes available, we should probably be careful not to have too many variants.
(Either way, this part is probably out of scope for now)