Specify supported Node/NPM versions in `engines` property within `package.json`

[adamstankiewicz]

Based on the discussion in this PR, we would like to consider adopting the following approach for managing Node.js version compatibility across micro-frontends.

---

Based on the guidance in this article, I believe what the author proposes for maintainers makes sense. We probably should be explicitly defining the supported Node.js version(s) in our repos/libraries with the engines property. I'd be curious to hear your thoughts, not just for this repository, but as a pattern more broadly.

• Define an engines property in the repo/library package.json files that declare the oldest active LTS version of Node.js (i.e., Node 18):

{
  "engines": {
    "node": "^18",
    "npm": "^9"
  }
}

• "When a Node.js version reaches end-of-life, even if your library is finished, bump a major version updating the engines field to the current oldest active LTS of Node.js."
• "Consider throwing a helpful exception if your library is used on an unsupported Node.js version."
• "Consider documenting your version support policy." See example from the aforementioned article.

---

### Tasks
- [ ] Create an `engines` property in all repos/libraries that rely on Node.js/NPM. Include the current oldest active LTS of Node.js and NPM.
- [ ] Create a new (Open edX) wiki page documenting this high-level approach to Node.js version upgrades, irrespective of which Node.js version it is. The page might be titled something like "Node.js Upgrade Lifecycle" and include the above outlined steps.
- [ ] Consider whether it's possible and/or makes sense to throw an exception if the repo/library is used on an unsupported Node.js version.
- [ ] Consider whether READMEs should be updated to include a version support policy similar to the example provided above,.