Support for unquoted config strings that start with number

[wallyqs]

Fixes parser to support string values that are not within quotes.

authorization {
  user = 3hello
  pass = 4world
}

Before it used to fail with an error as follows:

nats-server: Parse error on line 2: 'Expected a map value terminator "," or a map terminator "}", but got 'h' instead.'

• Documentation added (if applicable)
• Tests added
• Branch rebased on top of current master (git pull --rebase origin master)
• Changes squashed to a single commit (described here)
• Build is green in Travis CI
• You have certified that the contribution is your original work and that you license the work to the project under the Apache 2 license

Fixes #885

/cc @nats-io/core

[coveralls]

Coverage remained the same at 91.668% when pulling 47055ed on wallyqs:config-string-num-val into 36b9026 on nats-io:master.

[derekcollison]

My first question before even looking at code is what should this be? 12345678X. If numbers can only be all numbers I guess that is ok, but not sure how we handle that now.

[wallyqs]

Before this change, 123456789X would be undefined and cause a parsing error, for example:

log_file = 123456789X
// => nats-server: Parse error on line 8: 'Expected a top-level value to end with a new line, comment or EOF, but got 'X' instead.'

So the workaround is to put strings around log_file = "123456789X" which would work.

With the change in this branch now log_file = 123456789X without quotes is valid and treated as a string. There are some values that won't work as strings though, for example durations, which are given priority so that write_deadline = 5s even though it starts with a number it is still treated as a duration not as a string.

[derekcollison]

ok LGTM! Thanks..

[derekcollison]

LGTM