feat: Add configurable chartDirectory via separate RuntimeStates

[Ivo-Yankov]

Description

Adds initial versions of the following runtime config states:

• ExplorerConfigRuntimeState
• MirrorNodeConfigRuntimeState
• BlockNodeConfigRuntimeState
• JsonRpcRelayConfigRuntimeState

All of those states have their Schema, which for now only contains a helmChart configuration.
The runtime states are implemented into the respective Command classes, and the chartDirectory is read from them.

Removes the chartDirectory flag. The user can now set the chart directory via the following env variables:

SOLO_HELM-CHART_DIRECTORY=path/to/chart
SOLO_MIRROR_NODE_HELM-CHART_DIRECTORY=path/to/chart
SOLO_BLOCK_NODE_HELM-CHART_DIRECTORY=path/to/chart
SOLO_EXPLORER_HELM-CHART_DIRECTORY=path/to/chart
SOLO_JSON_RPC_RELAY_HELM-CHART_DIRECTORY=path/to/chart

Related Issues

• Closes #
• Related to #

Pull request (PR) checklist

• This PR added tests (unit, integration, and/or end-to-end)
• This PR updated documentation
• This PR added no TODOs or commented out code
• This PR has no breaking changes
• Any technical debt has been documented as a separate issue and linked to this PR
• Any package.json changes have been explained to and approved by a repository manager
• All related issues have been linked to this PR
• All changes in this PR are included in the description
• When this PR merges the commits will be squashed and the title will be used as the commit message, the 'commit message guidelines' below have been followed

Testing

• This PR added unit tests
• This PR added integration/end-to-end tests
• These changes required manual testing that is documented below
• Anything not tested is documented

The following manual testing was done:

• TBD

The following was not tested:

• TBD

Commit message guidelines

We use 'Conventional Commits' to ensure that our commit messages are easy to read, follow a consistent format, and for automated release note generation. Please follow the guidelines below when writing your commit messages:

1. BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type. NOTE: currently breaking changes will only bump the MAJOR version.
2. The title is prefixed with one of the following:

Prefix	Description	Semantic Version Update	Captured in Release Notes
feat:	a new feature	MINOR	Yes
fix:	a bug fix	PATCH	Yes
perf:	performance	PATCH	Yes
refactor:	code change that isn't feature or fix	none	No
test:	adding missing tests	none	No
docs:	changes to documentation	none	Yes
build:	changes to build process	none	No
ci:	changes to CI configuration	none	No
style:	formatting, missing semi-colons, etc	none	No
chore:	updating grunt tasks etc; no production code change	none	No

[github-actions]

Unit Test Results - Linux

32 tests  ±0   32 ✅ ±0   0s ⏱️ ±0s
16 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit e2c767f. ± Comparison against base commit aae5e1b.

♻️ This comment has been updated with latest results.

[github-actions]

Unit Test Results - Windows

  1 files  ± 0  142 suites  +20   3s ⏱️ -1s
403 tests +30  403 ✅ +30  0 💤 ±0  0 ❌ ±0 
415 runs  +38  415 ✅ +38  0 💤 ±0  0 ❌ ±0 

Results for commit e2c767f. ± Comparison against base commit aae5e1b.

♻️ This comment has been updated with latest results.

[nathanklick]

Review Hold

[andrewb1269hg]

Review and approve scripts folder changes.