Javascript improvements

[ojwb]

Gathering together things that have been suggested over various issues and PRs:

• JSDoc types which work with TypeScript (maybe done or at least mostly there now?) e.g. https://github.com/snowballstem/snowball/pull/221/files/f72e3e890587d55861e181c7cc81292471985a11#diff-9a44c8895826a0b981973faa0f4b2f28f018aabfde923d03a406f2a47e82a9f8
• Allow selecting a stemmer by passing an ISO-639 code (https://github.com/clearlylocal/snowball/blob/esm/esm/core/getStemmerByLocale.mjs but that just hard-codes them all whereas they should be generated from libstemmer/modules.txt)
• Add ES6 Support with Classes and Closures for JavaScript #221 used export default which seems to avoid the need to calculate the class name of the stemmer as well as the module name; the merged patch calculates both.
• Currently Snowball externals are generated as private methods (so treated just like Snowball routines) and then a fixed stemWord() public method is generated which sets the current word, calls #stem(), and returns the current word. This all seems a bit specific to the stemmers we ship rather than supporting the Snowball language in full. Conceptually wrong, but not all that important in practice. If there's a cleaner way to achieve this that would be nice though - e.g. we could apply the setting and getting of the current word to all externals and have a way to specify we want to map Snowball stem to Javascript stemWord() (e.g. this.stemWord = this.stem;)
• Add ES6 Support with Classes and Closures for JavaScript #221 Refactored stemwords.js to be fully async. Not entirely convinced that's helpful - at least to me it makes it harder to follow so worse in its partial role as an example of how to use the API, but maybe if you write a lot of JS async code it's actually easier to read in that form. It doesn't seem to be measurably faster as async either (it can probably parallelise IO with stemming a bit, but there is presumably extra overhead from the parallelism too).
• Would it be better to pass af from find_among to dispatch functions as a parameter: Emit JS classes #240 (comment)

[ojwb]

CI now runs deno check to check the types with || true after the command for now so we can see the current errors but CI still passes.

I have fixed the easy problems this highlighted, leaving essentially two:

• find_among()/find_among_b() take a call_among_func parameter which is only used if the among uses among functions. If it does, the among data (and array of arrays) will have a 4th element in some of the inner arrays. We pass null for this when there are no among functions. So there's an invariant ensured by the Snowball compiler, but it seems impossible to express here. I guess we could pass an arbitrary function instead of null but that doesn't seem better.

• The inner arrays in the among data are string, number, number, ?number but it seems you can only specify one type for array elements. We now use Array<Array<string|number>> but get type checking errors because we assume the first element is a string and the others are numbers. Again this is ensured by the Snowball compiler.

If anyone sees an easy workaround for either or both of these, please say.

I'm working on a new implementation of among for C which is O(length(suffix)) instead of something like O(log(#suffixes)*length(suffix)); it's also faster in practice, not just in O() - e.g. the current WIP version is ~19% faster for English and ~29% faster for Tamil. Maybe we'll end up adapting this approach for other target languages as well, in which case these problems might go away anyway.