[jslib] Refactored Acknowledgements with Enhanced HTTP Utilities

[HenriRabalais]

This PR refactors the acknowledgements page to use a new, more robust and reusable API client and a suite of custom error classes. This change modernizes our data fetching approach by moving away from raw fetch requests and adopting a structured, type-safe methodology.

Key Changes

Introduced a new Core Library: Added a new directory at jslib/core containing:

• Client.ts: A generic, extensible class for handling API requests (GET, POST, PUT). It includes robust error handling for network issues, HTTP response statuses (e.g., 404), and JSON parsing errors.
• Query.ts: A class for building type-safe URL query strings, supporting various operators and parameters.
• Added Custom Error Classes: A comprehensive set of custom error classes are now available at jslib/core/errors to provide more context for debugging API failures. This includes ApiNetworkError, ApiResponseError, JsonParseError, and more.

Introduced a Entities Library: Added a new directory at jslib/entities containing:

• Acknowledgment entity and affiliated type and client
• This will eventually house all LORIS entities, and contexts they provide, specific errors, hooks, components, etc.

Updated Acknowledgements Module

• The acknowledgementsIndex.js file has been refactored to use the new AcknowledgementClient instead of a raw fetch call. This significantly cleans up the component's logic and separates concerns.
• The AcknowledgementClient is a specialized client that extends the new generic Client.ts, providing an interface for interacting with the acknowledgements API.

Misc

• Module and Path Configuration: Updated package.json, tsconfig.json, and webpack.config.ts to support the new libraries, including:
• New dependencies: stream-browserify, pbkdf2, and transliteration.

[HenriRabalais]

needed to get things to load...

[HenriRabalais]

npm compile was giving errors without this

[HenriRabalais]

npm compile was giving errors without these

[HenriRabalais]

this is to allow each Client concrete class to define it's own errors across all the error types, not sure if it's the best implementation, but it seems to work — maybe it just needs a better name. return type be something like Record<string, string>

[HenriRabalais]

I can also replace this submission call in this PR to show the 'create' functionality.

[HenriRabalais]

@driusan @ridz1208 would love your thoughts on this! Hoping to extend this to more parts of loris after and add more entities. I'm also curious what you think of the directory structure I've started to build out, as it will likely get expanded. Should everything live in jslib? I'm thinking the top level components that currently live in jsx/ should also get moved into what ever the top level javascript directory is and live under a /components directory of sorts.