New Process Management?

In response to PR #145:

node-windows/mac/linux leverage a wrapper script to manage an underlying node script. The wrapper is managed by winsw in node-windows. This isn't ideal, because the architecture is basically a shim on top of a shim, and it uses things like opening a port to keep the wrapper running (not ideal).

The wrapper is responsible for features like automatic restart, stopping a process that repeatedly crashes, handling permission elevation, and maintaining a consistent API. The core logic is in the wrapper.

For the future of this project, there are several possible avenues.

**Option A** is updating winsw and the wrapper. This option still continues the shim-on-shim approach, but it keeps the logic in JavaScript.

**Option B** is to write a new shim, probably in Go. This would replace winsw entirely with the added advantage of only needing to maintain one code base instead of one for each OS... so these projects could be consolidated with fewer dependencies. This would be especially beneficial for maintaining node-linux, which would allow for systemd support instead of the now outdated systemv support.

I haven't made a decision, and won't until I have a chance to hear from folks. I'd appreciate feedback from anyone using this for mission critical apps.

My primary motivations for this project are:

1) Don't break anything that works today.
2) Don't change how the module is used (i.e. API)... focus on internal changes only.
3) Don't ostracize contributors.

I feel option B is a better overall technical implementation, offering a much more stable platform to work on. I also recognize most users are Node developers, not Go developers... but the overwhelming majority of people are users, not contributors. So, I'm not sure how much of a difference the internals truly make to everyone.

As is noted in the README, this project needs maintainers because my time is thin already. I do have resources (read: people) who could provide production support and continued maintenance/new feature development, but there are costs incurred for those resources and value delivered in the results of that work. I've never really considered making both open and commercially supported versions of this before, but this is a path some other projects are already headed down, specifically [Fenix](https://github.com/coreybutler/fenix)... so if anyone has a business interest in apps they're creating, there could be ways to better support that.