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.
This is done so that the actual error that is being thrown is bubbled higher up in the stack. The idea is that the exception isn't handled in the mongo tripod config object, but from where it's instantiated. So in the case of TARL, it would create the mongo tripod config object, which would throw an exception (if the config was borked) - TARL would either show an "uncaught exception" error, or it would be handled correctly with its own try/catch statement rather than right down in the bowels of the mongo tripod config object.