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.
Is it okay to assume VALUE_LITERAL exists in this circumstance?  Would it be better to leave this to crash if something goes wrong here, or should it be handled in this way?  (ie. is it better to simply fail, or to continue building the table without the count?)