perf: avoid slow exponentiation and repeated element reads

[lpatiny]

Speeds up the hot loops of the distance and similarity functions.

Algorithmic changes

• kumarJohnson: prod ** 1.5 → prod * Math.sqrt(prod). No engine specializes a 1.5 exponent, so this is the biggest win, on V8 and JavaScriptCore alike.
• minkowski: special-case p = 1 and p = 2. V8 sends x ** 1 through generic pow at ~9x the cost of a plain read; p = 2 is worth ~1.5x when called monomorphically.
• similarity.pearson: drop the two arrays it allocated only to mean-centre before calling cosine, folding the work into two passes.

Measured with beforeAfter.js, before → after, per element (n = 10000, Float64Array, node 24):

function	before	after
kumarJohnson	15.50 ns	2.41 ns	6.4x
similarity.pearson	19.06 ns	3.23 ns	5.9x
minkowski(p=1)	11.51 ns	2.02 ns	5.7x

For the other functions defining const like for example from:

  for (let i = 0; i < a.length; i++) {
    ans +=
      a[i] * Math.log((2 * a[i]) / (a[i] + b[i])) +
      b[i] * Math.log((2 * b[i]) / (a[i] + b[i]));
  }

to

 for (let i = 0; i < a.length; i++) {
    const ai = a[i];
    const bi = b[i];
    const sum = ai + bi;
    ans += ai * Math.log((2 * ai) / sum) + bi * Math.log((2 * bi) / sum);
  }

has no impact, neither with bun or with nodeJS except in the case of polymorphism (once a typed array, once a number array for example) and in this case we win a factor 1.5

But as a side observation changing the type of an array is really a bad idea and we are loosing a factor 2 in speed. I wonder if we can reach this kind of issue in some of our projects.

So practically I would still make this 'const' definition even if we win speed only in case of polymorphism. @targos WDYT ?