resolve conflict I created by merging incremental parsing before better-backend-handling. nothing interesting to see here

# Conflicts:
#   src/backends/packrat.c

Naive support for iterative parsing in packrat

See merge request hammer/hammer!51

Includes a test that exercises both.
Also fixes tracking of input position when suspending on the first chunk and
adapts h_input_stream_pos and h_input_stream_length to multi-chunk operation.

The naive implementation concatenates all input and blindly re-runs the full
parse on every chunk. Keeping state between chunks is for later.

Note: The iterative API expects us to always consume an entire input chunk
when we suspend, even if packrat later backtracks into it. We will produce
the correct parse result and accurately consume from a final chunk, but all
earlier chunks will be reported as fully consumed and as being part of the
HParseResult in terms of its bit_length field.

NB: The 'z' size modifier is in C99.

This commit changes the contract for the combinator parse functions:

 (1) The input state on failure must retain valid overrun and last_chunk
     fields. The latter is never changed, but overrun would be cleared by
     various combinators that backtrack in case of failure. All other
     fields of the input stream are still considered indeterminate after a
     failed parse.

 (2) If an overrun condition is encountered before the final chunk
     (last_chunk is false), the parse *must* fail. A helper want_suspend()
     is introduced as a shorthand for this check.

Fixes the packrat/iterative/dummy test.

There's no need.

This is the case where parsing stops, which may be a parse error or not,
depending on how many elements were read.

Replace it with an assert. This case could never occur because it tests
precisely the loop condition and there are no break statements in the loop.

This was the only use of the 'err' label, so that can go. The code under it
remains the fall-through case for 'err0', i.e. the actual error (parse failure)
case.

The test fails because currently parsers that fail may leave the input stream
in any indeterminate state. Parsers that backtrack (h_many, h_choice,
h_optional, etc.) do not propagate an overrun of their subordinate parsers to
h_packrat_parse_chunk where we would detect it and fail.

Also includes a very important cosmetic whitespace change.

Drive-by elimination of an age-old TODO. :)
Code should be functionally equivalent. Changes:

 - Remove broken code under CONSISTENCY_CHECK.
 - Transform to chip-away style.
 - Remove braces around single statements.
 - Declare variables at top of function.
 - Shorten some variable names (tmp_res and bit_length).
 - Limit line length to 80 columns.

A very first step. This implementation still expects all input in a single
chunk but allows the use of the iterative API. If the parser attempts to read
past the first chunk, the parse fails.

Contains some comments for next steps towards full support.

Adds tests for the single-chunk case.

add clang to tools if necessary

See merge request hammer/hammer!50

Ticket 95:  Fix backends with params that currently ignore requested params to use them.

Closes #95

See merge request hammer/hammer!49

Lets one, e.g., add -fPIC if compiling with GCC but linking with LLD.

clang appears to require -fPIC for shared objects on most platforms. the
'clang' tool adds the flag when appropriate. however, scons never selects the
clang tool automatically!

so we add the tool ourselves if CC=clang is set or generally on Darwin.

ideally, scons would know and handle all this, but at the time of writing
(scons v4.3.0), it does not.

WIP: arena allocator improvements

See merge request hammer/hammer!30

Improvements to requesting backend by name pulled out of the dlopen spike branch

See merge request PicoMeg/hammer!1

spike branch: parsing of more complex backend requested parameters
string, with optional paramaters, etc. formatting of code fixed, unused
string based parsing of request parameters removed, etc.

default of k=1 is used.

backends[backend]

right now there is duplication as the enum backend value is still
present- need to find out if it's OK to make a breaking change for
anyone who is for reasons known only to themselves chekcing which
backend enum value is one a parser they may have created and compiled...

vtable pointer, clean up some of the redundant information in backend
with params struct

HParserBackendWithParams