Merge pull request #53 from alphagov/function-predicates

Function predicates
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