chore(docs): bring examples into npm workspace

[dreamorosi]

Description of your changes

The repository uses npm workspaces to manage the different sections/packages of the codebase. Before this PR, the only two remaining entities that were still outside of the workspace were the examples found in examples/sam and examples/cdk.

One of the side effects of this setup was that the examples were using the versions of the Powertools utilities published on npm rather than using the ones in the repository. This meant that the examples could either go for long periods of time without getting updated or that maintainers had to manually bump the version after making a release, since due to how lerna works, during the release process the next npm version was not published yet at the time of versioning.

Another effect of this setup was that dependencies were being duplicated in at least 3 node_modules folders (the workspace one, as well as one for each example folder) and this caused additional management overhead whenever there was a version bump needed in any of the shared dependencies.

This PR aims at removing all these issues by bringing the two examples/* folders into the npm workspace, so that the examples can now be managed together with the rest of the other packages.

With this new setup, the dependencies of the two examples folders are managed at the workspace level. This has a few advantages:

• While versioning the workspace lerna is now able to effectively bump the Powertools utilities versions in the examples
• Most of the dependencies duplication has been removed
• The repo setup process has now been streamlined
• Future dependency version updates are now centralised.

Given that now all node_modules are handled centrally, this PR also simplifies the GitHub workflows by centralizing the caching in a dedicated local GitHub action, which can be found at .github/actions/cached-node-modules and that is used by all other workflows.

Related issues, RFCs

Issue number: #1407

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.