Previous behavior: When `/products` endpoint returned a http error, the code broke in [this line](https://github.com/SAP/spartacus/blob/ed1e1a78c488b1e1214491ffa736612287f8cf70/projects/core/src/product/store/effects/product.effect.ts#L77), complaining that `this` is undefined.

Fix: Preserve the context of `this` which was lost in [this line](https://github.com/SAP/spartacus/blob/ed1e1a78c488b1e1214491ffa736612287f8cf70/projects/core/src/product/store/effects/product.effect.ts#L52)

The problem was revealed only after we implemented [CXSPA-2251](https://jira.tools.sap/browse/CXSPA-2251) where we referenced `this` by adding `this.logger` to the method `ProductEffects.productLoadEffect`

fixes https://jira.tools.sap/browse/CXSPA-3902

Co-authored-by: Krzysztof Platis <[email protected]>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

Co-authored-by: Krzysztof Platis <[email protected]>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

# Conflicts:
#	projects/core/src/product/store/actions/product-references.action.ts
#	projects/core/src/product/store/actions/product-reviews.action.ts
#	projects/core/src/product/store/effects/product-reviews.effect.ts
#	projects/core/src/state/utils/entity-loader/entity-loader.action.ts

This pull request introduces methodologies for integrating multiple error interceptors that manage errors within the Server-Side Rendering (SSR) framework. This architectural augmentation preserves backward compatibility, mitigating any potential disruptions for end-users upon the incorporation of new error interceptors into the system.

With the introduction of this enhancement, it becomes easier for users to include new error interceptors, giving them the flexibility to determine the order in which these interceptors are applied within the system. This priority setting allows users to control how these interceptors operate and influence the workflow of the system.

The order is:
High priority
Normal or no priority
Low priority

Preserves the original order within a group of interceptors with the same priority.

…8662)

…I_ERROR_HANDLERS to singular form (#18776)

…t ExpressJS handlers (#18753)

#18999)

…#19009)

…pplications (#19028)

…ation method (#19031)

Co-authored-by: Krzysztof Platis <[email protected]>

In the past PR #17657 within this Epic branch, we made a lot of breaking changes. In that past PR we've also renamed public a lot of properties `public payload: any` to `public error: any` which was also a breaking change.

In this PR, we:
- revert those breaking changes.
  - bring back `public payload` property, if it was renamed to `public error`
  - bring back type `any` for `payload`/`error` properties that were changed to `ErrorActionType`
  - bring back the optional marker (`?`) for `payload`/`error`, that got removed the optional marker (`?`) 
  - bring back the old order of arguments of `EntityScopedFailAction`: `scope, error` vs `error, scope`
- additionally, we:
  - deprecate the signatures with the optional marker on the `payload`/`error` property, in favor of required params
  - widen type of `payload`/`error` to `any` from too-specific types like `ErrorModel`
  - pass missing `payload`/`error` parameter to super actions (like `ErrorActionType` etc.)
- fix some unit tests as a result of all above changes

Note for a reviewer:
The PR #19037 (not meant to be merged!) contains a full diff between this branch and the `develop` branch. You may want to check it to verify the current branch `feature/CXSPA-7198--v2` when merged to `epic/ssr-error-handling` will _really_ help to avoid _all_ breaking changes (related to ngrx actions) against `develop`

fixes https://jira.tools.sap/browse/CXSPA-7198

…ng errors to the server (#19021)

…rrorAction` (#19042)

…tion in fresh apps (#19055)

…19206)