Re-use parser/transform during interpolation

Can't reuse node interpreter, as it resolved a node, whereas an individual predicate depends
on a parent rule to me matched, eg a next node set.

The parse/transform repitition could more refactored away quite easily though, and means
the exact same models/logic can be reused for interpolation without any duplication. So
functions, et al, can be used.

This does require making NamedPredicate non-boolean, as question identifier defines as
optionaly including a ? at the end, which is reused by Named Predicate, meaning _any_
identifier like value ([a-zA-Z_0-9-]) gets parsed as a named predicate.

It named predicate is boolean, as it was before, then theres no way to get at the value
of the state by key, as it will always be a Named predicate.

For now, switch named predicate back to returning the value (which mostly gets treated
as boolean), but the proper fix is re-writing parsing to require named predicates to
have a ? at the end. That needs further thought though.

A better solution would be defining a variable type, which evaluates against state,
however that will impact on other definitions, eg, next node rules point at a node
and node name is based on identifier, which isn't a variable
Refactor NamedPredicate to require a trailing ?

Previously it was defined as an identifier, with an optional trailing '?',
which made it inditinguishable from an identifier, so any identifier would
be parsed as a NamedPredicate and return a boolean, not the value from state

This change means the identifier is not parsed at all, and is rescued by
```Parslet::ParseFailed```
so we can attempt to grab the value from state instead.

Eg,
- "%{hello}" will not parse, so we'll get the value from state instead
- "%{function()}" will parse as a FunctionPredicate, and get evaluated

This duplicates some of the evaluatable-or-state var from Functions[1],
where we could do with a Variable type object, that can be evaluated
and have a parsing rule to create them, so we can just assume everything
is evaluatable

This could break in some nasty ways on badly formed input, but that is
the existing behaviour, eg, a bad state var. So, not a regression

[1] https://github.com/alphagov/smartdown/commit/ff83ecc41d95eb84f1fcbdf54a1d5b39695d01d1#diff-cefc093efd4d3702a287586aae7f0fc0R15
Merge pull request #54 from alphagov/parsed-interpolation

Parsed interpolation values

This re-uses parsing/transform in interpolation, so it uses the same logic/code as functions/values/predicates in next node rules and conditionals.

This allows it to support function calls in interpolation, and any new parsable/evaluatable features added in the future should Just Work™ for interpolation as well.

To do this I had to update the parsing rules for named predicates, making a trailing ? required, otherwise it would parse pretty much everything as a named predicate. IMO this is a more readable convention anyway, but this may be a breaking change for some existing Smartdown flows that don't use the trailing ? pattern. We should note it in release notes and version bump accordingly.