Fix ParseResult and C-interface leaks. Fixes #234

Much needed redesign of the `ParseResult` architecture.

Basically the `ParseResult` is a compound type consisting of the node
being parsed, its source map and parse result. However this data
structure is used in three different scenarios:

1. Holding (owning) the data for the whole parse operation.
2. Passing references around the parsers routines.
3. Holding temporary data for some parser sub-routines especially when
processing collections of items.

Due to this I have splitted the structure into three different
structures to clearly distinguish their intended use and purpose:

1. `ParseResult` – to hold all the data for the whole parse operation,
see #1.
2. `IntermediateParseResult` – to provide a temporary buffer (owner)
for parser data before they are added to parent's `ParserResultRef`,
see #2.
3. `ParseResultRef` - to pass references to `ParseResult` and / or
`IntermediateParseResult`, see #3.

The rules of the thumb are:

1. Inside the parser, the `ParseResult` shouldn't be ever used.
2. Use `ParseResultRef` to pass references around the parser routines.
3. When a sub-routine needs to process only part of parent's
`ParseResultRef` create a new `ParseResultRef` referencing only the
relevant part.
4. Use `IntermediateParseResult` when you need a temporary Blueprint
AST node buffer (and its source map) for calling a sub-routine.
**NOTE** using `IntermediateParseResult` implies you might want to do
some additional post-subroutine operation most likely to add (copy)
some data from this temporary buffer to parents' `ParseResultRef`