Node: Npm bump

I’d like us to consider changing the way we handle npm inside of Node. Currently, we generally only touch the npm version with each Node release, but this behaviour contributed a little towards some of the issues discussed in #31777, because npm releases are outpacing Node releases considerably.

I’d like us to consider bumping the shipped npm version every 3 minor releases *(1.4.24 to 1.4.27)* or every 1 major release *(1.4.24 to 2.0.0)*, and revisioning the formula to nudge users onto that npm bump.

**Rationale**:

1) It’ll make debugging less of a pain in the neck, by reducing the vast environmental variable we currently have between Dave never updating his npm install, and Sandra constantly updating her npm install, and anything in-between.

2) It creates less room for things to go wrong towards the end of the install. A jump of a few versions is generally a lot smoother than a larger jump. It also means if we do start seeing issues we know it’s something in a relatively short, fairly-defined timeframe. *(Roughly, this change would ensure that nobody is using npm code older than 5 weeks)*. This also makes for *(marginally)* quicker installs for users as it shortens the npm stage a tiny touch.

3) We’re already adhering to the decision to bump users onto the latest npm release with each new install, and this roughly follows the same idea that we want to ensure users are using the newer npm versions.

**Potential issues**:

1) Theoretically, this could cause #31777 to flare back up more regularly than it did. I consider this a very low-change risk, based primarily on bullying the heck out of my system with successive npm upgrades in this manner over the last two weeks without issues.

2) It’s a wee bit more of a pain for users to have to upgrade Node every 5 weeks than every 2 or 3 months.

3) It makes the Node formula a little more high maintenance for the maintainers or me or Bob or Sandra or Dave who propose PRs on this subject to keep track of npm releases and handle the testing and revision process. Happy to sacrifice myself for this.

Ultimately, I’ll pass the decision on this over to the maintainers and their greater knowledge. This is something that has been on my mind & radar for a while now, but I wholly accept this could be something the maintainers decide to pass on.
Don't need `return` as the last statement. Just can be `s` after change above.