Teach `command` builtin a -p/--path flag

Give the `command` builtin a single flag, -p/--path, that causes it to
print the full path that would be executed for the given command.
Fix typo in documentation for `type` builtin
Fix `type` function to work better

Stop using getopt to parse flags. It's far more expensive than
necessary, and results in long flags not being parsed on OS X. This also
allows args starting with - after the options list to be properly
interpreted as a value to test.

Print the error message to stderr as is appropriate.

Use the new `command -p` functionality when the -a flag has not been
provided (`command` does not have any equivalent to the -a flag),
instead of using `which`. This is faster and also avoids any possible
disagreement between `which` and what fish thinks is valid.

Stop testing every path to see if it's executable, that test has already
been done by `which` or `command -p`.

The end result is `type -P ls` is roughly 250% faster, according to
profiling, on my OS X machine.
type: Separate the notion of multi and paths

Track whether -a and -f have been supplied separately. That way both
`type -a -f command` and `type -f -a command` behaves correctly, as does
`type -a -f foo` where there are multiple executables named `foo` in the
$PATH.
test: Add a new --quiet flag to suppress output

The --quiet flag is useful when only the exit status matters.

Fix the documentation for the -t flag to no longer claim that `type` can
print "keyword", as it never does that.

Stop printing a blank line for functions/builtins when the -p flag has
been passed. It's just not useful.
Adopt the new type -q flag in the other functions
type: Stop claiming `grep` is a function

Use `functions -q` instead of searching the `functiosn -na` list for the
provided word. This may result in an automatically-loaded function being
sourced, but that happens anyway with the default output.

This change means the results of `test -q foo` can be relied upon to
indicate whether `foo` can actually be invoked. Previosly, if `foo` was
the name of an automatically-loaded function file but did not actually
define a function `foo`, and there was no execuable `foo`, then `type -q
foo` would lie and say `foo` can be invoked when it can't.
Update tests for new `type` behavior

One of the tests was using `>/dev/null` to suppress the `type` output.
That needs to be `^/dev/null` now, but instead just go ahead and use the
new `-q` flag.
command: Rename -p/--path flag to -s/--search
read: Support arrays, character splitting

Enhance the `read` builtin to support creating an array with the --array
flag. With --array, only a single variable name is allowed and the
entire input is tokenized and placed into that variable as an array.

Also add custom behavior if IFS is empty or unset. In that event, split
the input on every character, instead of the previous behavior of doing
no splitting at all.
Fix `make test` to use local functions

When running `make test` we want to use the local function definitions,
not the ones installed on the system.

The system config.fish will still insert the system definitions at the
end, but at least ours will take precedence.
type: Restore combined flags behavior

Fix the parsing of `type` flags to handle combined short flags as
appropriate, e.g. `type -qf ls`.
Fix double expansions (`$$foo`)

Double expansions of variables had the following issues:

* `"$$foo"` threw an error no matter what the value of `$foo` was.
* `set -l foo ''; echo $$foo` threw an error because of the expansion of
  `$foo` to `''`.

With this change, double expansion always works properly. When
double-expanding a multi-valued variable, in a double-quoted string the
first word of the inner expansion is used for the outer expansion, and
outside of a quoted string every word is used for the double-expansion
in each of the arguments.

    > set -l foo bar baz
    > set -l bar one two
    > set -l baz three four
    > echo "$$foo"
    one two baz
    > echo $$foo
    one two three four
Parse slices even for empty variables

When a variable is parsed as being empty, parse out the slice and
validate the indexes anyway, behaving for slicing purposes as if the
variable had a single empty value.

Besides providing errors when expected, this also fixes the following:

    set -l foo
    echo "$foo[1]"

This used to print "[1]", now it properly prints nothing.
Highlight "$foo[1]" properly

Preserve the highlighting applied to the slice brackets when coloring
variables inside of double-quoted strings.
Fix highlighting of `"foo\"bar"`

The backslash-escape wasn't being properly caught by the highlighter.

Also remove the highlighting of `"\'"`, as `\'` is not a valid escape in
double-quotes, and add highlighting for a backslash-escaped newline.
Color `"$foo[1"` as an error

We can't color the whole argument as an error, since the tokenizer is
responsible for that and doesn't care abou this case, but we can color
the `$foo[` bit as an error.
Fix error span for invalid slice indexes

The span now properly points at the token that was invalid, rather than
the start of the slice.

Also fix the span for `()[1]` and `()[d]`, which were previously
reporting no source location at all.
set: Print an error when setting `umask` to a bad value

Repurpose the ENV_INVALID return value for env_set(), which wasn't
currently used by anything. When a bad value is passed for the 'umask'
key, return ENV_INVALID to signal this and print a good error message
from the `set` builtin.

This makes `set umask foo` properly produce an error.
doc: Fix links in "Further help and development"

Hyperlink the mailing list to the proper info page.

Tweak the GitHub link to use https.