feat: add support for exports not named the same as the class

[Julusian]

Raised from nrkno/sofie-atem-connection#74

In some cases the name of the export may not match the name of the class. Often when the code is minified, or re-exported over multiple levels from a library.

I am not entirely happy with the solution here, as there are a bunch of parameters now for different threading modes. @nytamin perhaps you will have some ideas to tidy it up?

[nytamin]

I suppose that you're right, this might be a necessary solution in certain cases.

I'm not a fan of requiring the name for all Classes though, perhaps you could add an overloaded function to threadedClass() that, when class-name is omitted, defaults to using myClass.name? That way, it might be backwards compatible as well?

[Julusian]

I'm not a fan of requiring the name for all Classes though

Maybe so, but this can be hit by a project minifying its code and where threadedclass is used inside a dependency. And the fix will be for that dependency author to supply this parameter. (eg, the reason this was discovered)

I would prefer to instead not pass in the class, and for single threaded mode to load the class in the same way as multithreaded does (to ensure it does behave the same). I did a quick attempt at that but it was really unhappy so I abandoned it for now

[Julusian]

@nytamin I have reworked this and removed the orgClass parameter instead, as apparently doing that does work without issue.

So the number of parameters is the same, but instead of supplying the class the name of the export is needed.

I think this is much better and safer, as it was possible to get different results in single vs multithreaded due to them getting the class in very different ways

[nytamin]

looks good!

[Julusian]

TODO: Update readme and examples