Jp/first workers

[TheJeran]

This is the first batch of workers for array tasks as mentioned in #601. It just applies to GetCurrentArray() with its counterpart GetCurrentArrayWorkers(). For uncompressed data there isn't a very notable speed-up. Maybe on very large datasets. But for compressed data the speed-up is very noticeable.

Trying to think of the most efficient application of workers to the data fetching itself. At the Moment may just create workers for data conversion as I haven't found a way to read netcdf data within the workers. Zarr can fetch in workers, but each worker must initialize the store every time which is inefficient.

Also fixed a bug in the new GetArray() function which looks at fetchNC value. However, this can be true even wheil fetching zarr. So now it checks if fetchNC is true AND the initstore is Local. Then it's a NC for sure.

[gemini-code-assist]

Code Review

This pull request introduces parallelized data processing using Web Workers and SharedArrayBuffer through a new GetCurrentArrayWorkers utility. Corresponding updates were made to AnalysisWG and FlatMap to support asynchronous data retrieval. Feedback highlights critical compatibility concerns regarding SharedArrayBuffer and cross-origin isolation, a potential logic bug where the worker promise might hang if no tasks are present, and issues with path aliases in worker initialization. Additionally, a typo was found in a performance optimization within the texture generation logic.

[gemini-code-assist]

SharedArrayBuffer is only available in environments that are cross-origin isolated (requiring specific HTTP headers like COOP and COEP). In non-isolated environments, this will throw a ReferenceError. Consider adding a check for typeof SharedArrayBuffer !== 'undefined' and providing a fallback to regular ArrayBuffer or the non-worker implementation.

[TheJeran]

@lazarusA This is why it needed to be in the config

[gemini-code-assist]

If the tasks array is empty, the workers array will also be empty, and the Promise will never resolve because the dispatch logic is only triggered for existing workers. This will cause the function to hang. You should handle the case where no tasks are generated.

  if (tasks.length === 0) {
    setStatus(null)
    return new Float16Array(sharedBuffer)
  }

  await new Promise<void>((resolve, reject) => {