chore: add hypercube generic functions to nebuls.js, part01

[Donya-qlik]

Motivation

Moving generic hypercube functions from sense-client to nebula.js - Part01.
At this PR only the functions that are required to display the fields in property-panel are considered. The rest of the functions will be moved to this repo in the coming PRs.

The source files for these functions are in sense-client (data-property-handler.ts & hypercube-handler.js)

Required Flag: NEBULA_DATA_HANDLERS

Requirements checklist

• Api specification
  • Ran yarn spec
    • No changes OR API changes has been formally approved
• Unit/Component test coverage
• Correct PR title for the changes (fix, chore, feat)

When build and tests have passed:

• Add code reviewers, for example @qlik-oss/nebula-core

[Copilot]

Copilot reviewed 9 out of 11 changed files in this pull request and generated 1 comment.

Files not reviewed (2)

• apis/nucleus/package.json: Language not supported
• package.json: Language not supported

[Copilot]

Copilot reviewed 8 out of 11 changed files in this pull request and generated no comments.

Files not reviewed (3)

• apis/nucleus/package.json: Language not supported
• apis/stardust/api-spec/spec.json: Language not supported
• package.json: Language not supported

Comments suppressed due to low confidence (2)

apis/nucleus/src/utils/handlers/hypercube-handlers.js:23

• [nitpick] The inline ternary inside the template literal is redundant. Consider simplifying the expression to use ${this.path}.qHyperCubeDef when this.path exists for improved clarity.

      ? utils.getValue(properties, `${this.path ? `${this.path}.` : ''}qHyperCubeDef`)

apis/conversion/src/array-util.js:77

• [nitpick] Using Array.isArray(array) is generally preferred over instanceof Array for broad reliability across different execution contexts.

  if (!(array instanceof Array)) {

[Copilot]

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

[Donya-qlik]

@Caele I added the flag so it works only when the flag is enabled. Do you think the PR is ready to merge?

Btw, I disabled checking Eslint for some imports from the other packages for now, since you mentioned we prefer to not to add other packages dependencies. But we should probably come up with a better solution for that, maybe moving those util functions to the parent package so they can be easily called in different packages without necessity to add a specific dependency?
If it makes sense, I can do that in a separated PR.

[Caele]

Can go ahead with this now. Not sure about the extra line in the spec file. but thats probably an auto fix thing.