Add support for the ERDDAP syntax to the DAP4 CE scanner and parser.

[jgallagher59701]

I started with the ERDDAP syntax task since I'd like to understand why this was so hard we dropped it. There are no note in the code, but the issue seems to be that in DAP4 '.' is a PATH_SEP in the syntax of the DAP4 CE and so the scanner tokenizes "[(30.6)]..." as LBRACKET LPAREN WORD PATH_SEP and then fails hard.

libdap4/tests % ./dmr-test -S -c "[(45.0)]"
LBRACKET
LPAREN
WORD: 45
PATH_SEP
Assertion failed: (!yytypeid_), function emplace, file d4_ce_parser.tab.hh, line 222.

OTOH, "[(30)]..." scans just fine:

libdap4/tests % ./dmr-test -S -c "[(30)]" 
LBRACKET
LPAREN
WORD: 30
RPAREN
RBRACKET

as does

libdap4/tests % ./dmr-test -S -c "[(45.)]"  
LBRACKET
LPAREN
WORD: 45
PATH_SEP
RPAREN
RBRACKET

One possible solution is to define FLOAT as a floating point number and then change the parser so that it will recognize [(WORD)] and [(FLOAT)] as 'value' subsets.

Another possible solution, which might be cleaner for the parser implementation, is to use a scanner state (as we do for strings) to pick out the start of a SUBSET_VALUE when it scans a '(' and grab everything until the closing ')'.

[jgallagher59701]

The code on the jhrg/subset-by-value branch is close WRT parsing (there's no logic once it parses the values). The current behavior is to parse by regardless of the values, the entire dimension is projected. However, the assignment of projections to Maps does not parse. For example:

./dmr-test -x -e -t dmr-testsuite/vol_1_ce_7.xml -c 'nlon=[0:2];nlat=[(0):(3)];temp[][]'

Fails. Fix that and then cycle back to the grid() and/or geogrinf() functions.

[jgallagher59701]

It parses now - the index object returned is a placeholder, but the parsing works.

Add tests and close this.

[jgallagher59701]

Added tests