Adding count and regex to tablespec - 90%

Views can contain a `count` with `filter`. When they do, they must also have a `ttl` (time to live) property which tells tripod the maximum age of the view before it is regenerated. Such views do not rely on the `impactIndex` to detect changes because due to the join-y nature of the filter it is possible to change data conditions referenced by a filter downstream of the view which will affect the count.

Time to live invalidation is fine for views because they only span one document, it is easy to regenerate a single view in the foreground on read if it is found to exceed it's time to live.

We also want the `count` functionality for tables. However, we must be more careful. Table rows can span 1000's or more documents. A `ttl` here is not a good strategy - tables are read out in pages and we cannot know without reading the whole set whether there is stale data. This would also make it impossible to output a page header in the result set that contains a total count.

So we must implement `count` function for tables that does not require a `ttl`. This means the `filter` conditions for tables must be more restrictive and cannot possibly filter data that cannot be detected by the `impactIndex`.

This branch contains the ability to specify a count for a table thus:

```javascript
        {
            "_id": "t_source_count_regex",
            "type":"acorn:Resource",
            "from":"CBD_testing",
            "fields": [
                {
                    "fieldName": "type",
                    "predicates": ["rdf:type"]
                }
            ],
            "counts" : {
                "source_count": {
                    "property" : "dct:isVersionOf"
                },
                "regex_source_count": {
                    "property" : "dct:isVersionOf",
                    "regex" : "/foobar/"
                }
            }
        }
```

Here we see two forms of count. Firstly, a simple predicate count and the second with an optional "regex" filter. The regex is applied to the property value (one by one, whether it is a uri or a literal) and only counted if the regex matches. This allows us some degree of filtering but crucially not across a CBD boundary so we don't have to impose the `ttl` pattern we have for more complex counts on views.

The major question about this approach...

Maybe `regex` isn't the best strategy here, regex is expensive and maybe a simpler `strpos` check and a change of the keyword to `contains`? This would be more performant but looses the full power of regex.
Yup - an additional test - not to do with counts