Change lifecycle to support Linux and Windows

[micahyoung]

Change lifecycle to support Linux and Windows

- Default Windows shell is Command Prompt (cmd.exe)
- Lifecycle binaries on Windows can be `.exe` or `.bat`
- Buildpack binaries on WIndows can be `.exe` or `.bat`
- Profile scripts are Batch Script (.bat) format
- Processes started with `direct = false` are loaded with Command Prompt
- CNB_*IDs should be SIDs on Windows

Readable

RFC PR

[micahyoung]

Opening this proposed spec PR to aid in discussion.

There's still a remaining open question from the RFC PR from @jkutner on whether Windows should be defined in an extension instead. Hopefully this diff - with what is hopefully a near-complete set of changes - can help that decision.

[zmackie]

WG comments: can "shell" in lifecycle.md footnote to the "shell" in the readme to make sure its clear that windows shell == .bat compatible and linux == bash 3+?

[hone]

I'm not sure of a good example in specs, but Rust elegantly has a broad abstraction and then use extension traits to handle it. You can find all the OS extensions as part of std::os. A good example is not using modes directly like most other languages. For instance, Node.js has a modes parameter to many fs methods with the caveat documented:

Caveats: on Windows only the write permission can be changed, and the distinction among the permissions of group, owner or others is not implemented.

In Rust, modes is exclusive to the Unix Extension. Another example is getting information about a file. Rust has a struct std::fs::Metadata that is generic across all platforms, but then provides extension specific traits for both Windows and Unix.

I wonder for CNB (not blocking this PR), but if we want to re-organize to have OS specific "extensions" (documentation) that is more encapsulating that can be referenced out to.

[nebhale]

Resolved by 2a8ca60