ConfigMap updates, add Client helper script

Description

When testing previous Client chart changes, I ran into some difficulty figuring out how to use the client commands. I received some help, and thought it would be useful to distill that learning and make it easier to for others use for debugging purposes.

This PR does two things, first it renames some ConfigMaps to indicate that they contain helper scripts.

The second and main change, is to add a helper script for use within Client containers to run m0* commands. Here's example usage:

❯ kubectl exec -it cortx-client-0 -c cortx-motr-client-001 -- /bin/bash
[root@cortx-client-0 /]# . /scripts/motr-env.sh
[root@cortx-client-0 /]# env | grep ^MOTR
MOTR_PROFILE_FID=0x7000000000000001:0x0
MOTR_PROCESS_FID=0x7200000000000001:0xc
MOTR_CLIENT_EP=inet:tcp:cortx-client-0.cortx-client-headless.cortx.svc.cluster.local@21501
MOTR_HA_EP=inet:tcp:cortx-client-0.cortx-client-headless.cortx.svc.cluster.local@22001
[root@cortx-client-0 /]# dd if=/dev/urandom of=/tmp/128M bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 1.12547 s, 119 MB/s
[root@cortx-client-0 /]# m0shim m0cp --object 12:34 --block-size 1m --block-count 16 --layout-id 9 /tmp/128M
[root@cortx-client-0 /]# m0shim m0cp --object 12:34 --block-size 1m --block-count 16 --layout-id 9 /tmp/128M
Object 12:34 already exists: rc=-17. To update an existing object, use -u=start index.
[root@cortx-client-0 /]# m0shim m0mkfs --help
Unsupported m0 command

First, you exec into one of the Client containers. Each container has an "index" environment variable, which designates which client it is in relation to the Motr configuration. The script fetches information about the client (using hctl fetch-fids) and stores them in environment variables. When sourcing the script, it will export those env vars, and provide a m0shim bash function. This function allows the calling of a select handful of m0* commands and automatically sets some required command line arguments. I picked the commands that looked interesting, but I don't have much practical experience with them.

Breaking change

Type of change

[ ] Bug fix (non-breaking change that fixes an issue)
[X] New feature (non-breaking change that adds new functionality)
[ ] Breaking change (bug fix or new feature that breaks existing functionality)
[ ] Third-party dependency update
[ ] Documentation additions or improvements
[ ] Code quality improvements to existing code or test additions/updates

Applicable issues

This change fixes an issue:

How was this tested?

See usage example above.

Checklist

[X] The change is tested and works locally.
[ ] New or changed settings in the solution YAML are documented clearly in the README.md file.
[X] All commits are signed off and are in agreement with the CORTX Community DCO and CLA policy.

If this change requires newer CORTX or third party image versions:

[ ] The image fields in solution.example.yaml have been updated to use the required versions.
[ ] The appVersion field of the Helm chart has been updated to use the new CORTX version.

If this change addresses a CORTX Jira issue:

[ ] The title of the PR starts with the issue ID (e.g. CORTX-XXXXX:)

Seagate / cortx-k8s