revisit environmentVar definitions #249

as agreed in a meeting with @mrutkows , @stevespringett , @jkowalleck
we will keep things as proposed via #222 for a while and revisit and restructure things in a breaking changes release.

see all of these:

• Added formulation support and test cases #222 (comment)
• Added formulation support and test cases #222 (comment)
• Added formulation support and test cases #222 (comment)
• Added formulation support and test cases #222 (comment)
• Added formulation support and test cases #222 (comment)
• see Please do not reuse propertyType for "environmentVar " #248
• see BC: Address problems with v1.5 introducing arrays where items are "oneOf"different types #270

yet another problem: @mrutkows mentioned that the envVars are allowed to be "string", instead of key-value(KV) pairs, for the purpose to document a POSIX variable set.
This 'POSIX variable set' is not only undocumented, but in fact contra productive. have it documented and give it a format(regex), so parsers/validators know how to read it!
In the end a 'POSIX variable set' is claimed to be just a certain notation of KV.
Better: remove the string option entirely, use properly defined KV only.

currently valid:

{
// [...]
  "environmentVars": [
    {
      // no issues here
      "name": "foo",
      "value": "bar"
    },
    {
      // issue: empty name/value
      "name": "",
      "value": ""
    },
    {
      // issue: no name
      "value": "foobar"
    },
    {
      //issue:  no value
      "name": "foobar"
    },
    {
      // issue: empty object
    },
    // issue: `string` does not have a defined format. who knows how to create it, who knows how to use or parse it.
    "bazz", // some arbitrary strig
    "$HOME=/home/user1", // posix like
    "$Env:Foo = 'An example'", //  powershell notation
    "", // empty string
    // [...]
  ],
// [...]
}