tokenize-786661: Param order: assert.is(actual, expected);

Unit tests in GCLI have changed. Originally assert.is() was called
equals() and the order was equals(expected, actual) because it seemed to
make sense to have the expected thing first, however if the function
name is 'is' then you have to put the 'actual' parameter first. When we
changed from 'equals' to 'is' (to match mochitest) we didn't swap the
orders of the params (but added new asserts the new way). This corrects
that and fixes the orders of the params.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: Pass context to lookup/max/min

Some time ago we started passing context to parse, but now we need to
push it further, to lookup in selection and max/min in number.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: s/context/executionContext

Previously we split context into executionContext and conversionContext
but failed to propagate the change to a few places. This fixes those.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: Remove unused function

Signed-off-by: Joe Walker <jwalker@mozilla.com>
fixdebug-834230: Expose the Event constructor

It's used by cli.js, and the basic Firefox JSM environment doesn't
expose this by default.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
tokenize-786661: Move some escaping to string type

There are 2 distinct reasons for escaping:
1. allow typing untypable chars (\t, \n, etc)
2. preventing gcli from treating chars like ', ", [space], {, } as
   special

So the tokenizer needs to think about 2, but not 1, and 1 should be
handled by the type system; just as we convert "42" to 42 when the type
is a number, so we should convert "\t" to a TAB char when the type is a
string.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
tokenize-786661: Minor comment update

Signed-off-by: Joe Walker <jwalker@mozilla.com>
tokenize-786661: Fix handling of \\n

We were previously making errors due to the double parsing that we were
doing, rather than write our own code to step through we just do the
replacement in 2 steps. See code comments for details.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
allowblank-866680: Add string option to allow blank strings

There are many cases where a string is required and a blank won't do
(for example the "context <name>" command) so we need to provide for the
"empty string is invalid" case too.

The question is should we make the cookie command say

          {
            name: "path",
            type: { name: "string", allowBlank: true },
            ...
          },

Or should the context command say:

          {
            name: "name",
            type: { name: "string", forceValue: true },
            ...
          },

I think there are 2 reasons to prefer allowBlank: true

1. It doesn't change the current default
2. Having defaultValue: '' does nearly the same thing, allowing the user
   to not type a value. This is only an issue where there is a string
   where blank is valid, but there is a non-blank defaultValue

Signed-off-by: Joe Walker <jwalker@mozilla.com>
allowblank-866680: Legally blank parameter hints

Previously for "cookie --path ''" we were still showing the hint for the
path even though we'd clearly entered an empty string. This was because
the test for whether or not we'd entered data was whether the text
of the argument was empty, now we test to see if there is an argument
which means that "" (i.e. no text but valid argument) no longer shows
the hint.

Signed-off-by: Joe Walker <jwalker@mozilla.com>
Merge branch 'date2-773271' into landing
Merge branch 'fixdebug-834230' into landing
Merge branch 'date2-773271' into landing
date-773271: Use getBlah rather than getUTCBlah

We should be consistently using local time.

Signed-off-by: Joe Walker <jwalker@mozilla.com>