Namespace plugin storage keys per authenticated user

[taban03]

Proposed changes

context.storage is plugin-scoped and shared by every user of the
plugin across local/cluster/HA back-ends. The storage router bound
get/set/delete/getAll/setAll/deleteAll directly to it with no
ownership check, so any authenticated user could read another user's
entries, overwrite them, or wipe the entire plugin namespace via
DELETE /.

Every key is now namespaced as ${req.username}:${key} before
reaching context.storage. GET/POST/DELETE / are scoped to only the
caller's own prefixed keys instead of operating on the whole
plugin-wide dictionary; GET/POST/DELETE /:key operate on the caller's
own namespaced key. A guard middleware rejects requests with no
authenticated username.

This PR addresses Issue: [Link to Github issue within https://github.com/zowe/zlux/issues if any]

This PR depends upon the following PRs:

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Change in a documentation
• Refactor the code
• Chore, repository cleanup, updates the dependencies.
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

PR Checklist

Please delete options that are not relevant.

• If the changes in this PR are meant for the next release / mainline, this PR targets the "staging" branch.
• My code follows the style guidelines of this project (see: Contributing guideline)
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• New and existing unit tests pass locally with my changes
• video or image is included if visual changes are made
• Relevant update to CHANGELOG.md
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works, or describe a test method below

Testing

Further comments

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[1000TurquoisePogs]

This was never really a security risk, but it's also not an issue to fix so fine by me.