config: Adjust process.args to cite POSIX's execvp

This punts the awkward-to-enforce "MUST be available at the given path
inside of the rootfs" to the kernel, which will do a much better job
of enforcing that constraint than runtime code or a static validator.

It also punts most of the semantics to POSIX, which does a better job
than we'll do at specifying this.  The extension is necessary because
POSIX allows argv to be empty.  In the DESCRIPTION:

  The argument arg0 should point to a filename that is associated with
  the process being started by one of the exec functions.

And in RATIONALE:

  Early proposals required that the value of argc passed to main() be
  "one or greater".  This was driven by the same requirement in drafts
  of the ISO C standard.  In fact, historical implementations have
  passed a value of zero when no arguments are supplied to the caller
  of the exec functions.  This requirement was removed from the ISO C
  standard and subsequently removed from this volume of IEEE Std
  1003.1-2001 as well.  The wording, in particular the use of the word
  should, requires a Strictly Conforming POSIX Application to pass at
  least one argument to the exec function, thus guaranteeing that argc
  be one or greater when invoked by such an application.  In fact,
  this is good practice, since many existing applications reference
  argv[0] without first checking the value of argc.

But with an empty 'args' we will have no process to call (since
process lacks an explicit 'file' analog).

I chose the 2001/2004 POSIX spec for consistency with the existing
reference (which landed in 7ac41c6, config.md: reformat into a
standard style, 2015-06-30, which did not motivate it's use of an
older standard).  For 2001 vs. 2004, [1] has:

  Abstract: The 2004 edition incorporates Technical Corrigendum Number
  1 and Technical Corrigendum 2 addressing problems discovered since
  the approval of the 2001 edition. These are mainly due to resolving
  integration issues raised by the merger of the Base documents.

and the text in the linked pages uses "IEEE Std 1003.1-2001" for
internal linking.

Rob Dolin had suggested "platform-appropriate" wording [2], but it
seems like Visual Studio 2015 supports execvp [3], and providing an
explicit "platform-appropriate" wiggle seems like it's adding useless
complication.

[1]: http://pubs.opengroup.org/onlinepubs/009695399/mindex.html
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-18-17.01.log.html#l-54
[3]: https://msdn.microsoft.com/en-us/library/3xw6zy53.aspx

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

config.md

@@ -89,7 +89,8 @@ See links for details about [mountvol](http://ss64.com/nt/mountvol.html) and [Se
 * **`terminal`** (bool, optional) specifies whether you want a terminal attached to that process. Defaults to false.
 * **`cwd`** (string, required) is the working directory that will be set for the executable. This value MUST be an absolute path.
 * **`env`** (array of strings, optional) with the same semantics as [IEEE Std 1003.1-2001's `environ`][ieee-1003.1-2001-xbd-c8.1].
-* **`args`** (array of strings, required) executable to launch and any flags as an array. The executable is the first element and MUST be available at the given path inside of the rootfs. If the executable path is not an absolute path then the search $PATH is interpreted to find the executable.
+* **`args`** (array of strings, required) with similar semantics to [IEEE Std 1003.1-2001 `execvp`'s *argv*][ieee-1003.1-2001-xsh-exec].
+  This specification extends the IEEE standard in that at least one entry is REQUIRED, and that entry is used with the same semantics as `execvp`'s *file*.
 
 For Linux-based systems the process structure supports the following process specific fields:
 
@@ -669,6 +670,7 @@ Here is a full example `config.json` for reference.
 ```
 
 [ieee-1003.1-2001-xbd-c8.1]: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_01
+[ieee-1003.1-2001-xsh-exec]: http://pubs.opengroup.org/onlinepubs/009695399/functions/exec.html
 [runtime-namespace]: glossary.md#runtime-namespace
 [uts-namespace]: http://man7.org/linux/man-pages/man7/namespaces.7.html
 [go-environment]: https://golang.org/doc/install/source#environment