Let predicates self describe in a human form

Useful for debugging, and can be used in graph visualisations.

Currently graph visualisation has to know about each predicate
and it's internal implementation, this puts that repsonsibility
into the predicate itself
Merge pull request #52 from alphagov/human_predicate_models

Let predicates self describe in a human form
Add function 'predicate'

This is a bit of a stretch of 'predicate', as they should be boolean, but that is
the naming convention everything else uses at the moment, so stay consistent.

- Parsing rules for a function predicate that looks like `function_name(arg_1, arg_2)`
- Transform to a Function model, which can evaluate the function and return it's result.
- The `with_eval` is a hack to get around State auto-calling any callable object, as its
  fetched from state. Changing that behaviour affects a lot of things, and I want to keep
  this commit small, so with_eval is a briding solutuin to get this working first. It
  should be removed shortly.
- Function args can be other callables (functions, predicates), if not they are assumed
  to be variables on state. This is a bit hackt, and we're probably missing a variable
  like model, which represents a value in state by nane, but has a evaluate interface
  the same as everything else
- It's assumed functions will be defined on state, either as a built-in, or
  injected by an external application when the flow is created.
Don't automaticaly call callable state values

The auto call behaviour was added in:
- https://github.com/alphagov/smartdown/commit/7f580593e6bf457bd228e81bb0d217f876a35ab0

With the assumption it would support plugins in the future.

Not auto-calling callables returned from state lets us get back plugin/function
values from state and let them be called by Function, with it's own choice of
arguments.

- This was bound up in engine tests as it (ab)used the behaviour to inject a
set-membership like test into state.
- The Otherwise predicate was implemented as a lambda auto-called from state,
  so I have added an Otherwise predicate that evaluates to true, which is the
  same behaviour
- This commit makes all the tests pass, with auto-call removed, but may not
cover all cases if test coverage is missing. That said, i'm 99% confident
this shouldn't break anything.
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
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.
Answers are now typed objects

Question models know answer type
Raw answers parsed into Smartdown::Model::Answers
as they are processed by Engine.
Model::Answer objects correctly handle comparing against strings

Predicates generally compare answers against strings, so we want
the comparison methods of Answers to parse the compared value before
evaluating the comparison.
Answers support #evaluate
SetMembership predicate evaluates using :== on state member

instead of using :== on the value string. This means we can correctly
compare strings with answer objects.