Add 'ppm' bins to complement existing 'apm' bins

[DeeDeeG]

I think the PR title pretty much says what's going on here, but my extended thoughts below for anyone curious

Makes it easier to integrate ppm in various contexts, such as on the user's PATH to be run from the CLI, without having to run it as 'apm'.

Notably, this should make it easier to get a ppm.cmd command on users' PATHs on Windows, based on the method we've been using so far, which thus far has ended up giving users an apm.cmd command on Windows...

Aside/commentary: It also subjectively lets us do something less "jank" feeling than for ppm to be a symlink to apm on Unix-likes (Linux + macOS)... We can do ppm --> ppm instead now... But that hasn't been an issue thus far, honestly. I don't worry myself over that one, truthfully. It's just been an itch at the back of my neck to finally do this, I suppose, and the Windows integration gave me a real reason to finally do so.

Leaving the old 'apm' and 'apm.cmd' bins in case these are useful for troubleshooting during the transition to 'ppm'-named bins, or in case some edge case requires them.

(They're two small text files, I think we can afford to keep ones with either name, at least for now, if not forever. We'll see what's best.)

And less importantly, but relatedly...

Also adjusted a script that sets the correct file permissions on Windows, although this is really only relevant for sharing the files in archives (tarballs definitely, not sure if it affects zip files) -- notably when uploading the (packed, tarballed) package to the npm registry.

We do not publish ppm to the npm package registry, unlike what they used to do with apm. So, this doesn't really apply to us. Still, I wanted there to be parity / no bit-rot in this "legacy code" in case we change our minds and start publishing ppm to the npm package registry again like they did with apm. (Or else we can delete said code, on way or the other. I vote for keeping it, since it's not doing any harm, IMO... Less churn = less unexpected issues. Low stakes, might as well keep it, again IMO).

[DeeDeeG]

Restating a key point in case that wall of text above was too long:

I opted for adding new bins (ppm and ppm.cmd), and leaving apm and apm.cmd for now until we're 1000% sure removing them hasn't broken anything, and to leave people the option to integrate how they wish -- we can use exclusively the ppm ones in our own first-party stuff, and let third parties do what they want??? Or just delete the apm ones as soon as we are sure nothing breaks with them gone. Either way...

I figure this is the lower-risk way to get the ppm and ppm.cmd bins out the door and shipped into Pulsar core. Though the other way isn't high risk that I can tell, so if we're set on it, we can just do so. It's just that the cost of doing it this was is virtually zero to us, IMO, so... Yeah, I went with this. Seems safe and low-cost to us/potential ecosystem integrations.

I still expect us to stop symlinking to the apm bin on Linux/macOS and instead link to the ppm one. And the ppm.cmd should be useful on Windows for sure, according to what I've heard @confused-Techie saying about this so far.

[DeeDeeG]

Codacy wants me to change code style in the middle of an existing JS file by adding a semicolon... 🤦

Suggested diff:

  fs.chmodSync(path.join(__dirname, '..', 'bin', 'apm'), 0o755)
- fs.chmodSync(path.join(__dirname, '..', 'bin', 'ppm'), 0o755)
+ fs.chmodSync(path.join(__dirname, '..', 'bin', 'ppm'), 0o755);
  fs.chmodSync(path.join(__dirname, '..', 'bin', 'npm'), 0o755)

(I'm not gonna do that, sorry Codacy.)