feat: Add count aggregate support

[AndrewSisley]

Closes #93

Adds count aggregate support within object and commit queries. Adjusts the render system slightly, introducing a new _hidden field allowing records to be yielded through nodes, but not outputted to the query consumer (in this case, it saves a lot of hassle when counting with a limit/offset on the child collection).

• Have talk on many-nodes vs aggregate node
• Update Tech-doc post merge

[jsimnz]

A few comments/thoughts/issues.

Biggest gripe is the implementation of aggregate funcs as individual planNodes. We can talk about this during the next call.

[jsimnz]

I mentioned this briefly in the convo on #28... My reservation about making each aggregate func its own dedicated node is that it will inflate the plan graph notably for queries that use a notable number of aggregates. Especially if youre thinking about composing aggregates out of other aggregates (IE: Avg from Sum and Count).

Especially if to implement a single aggregate func, we need to define an entire planNode with methods that have very little to do with the process of aggregation.

[AndrewSisley]

I don't worry so much about the size of the graph, and the graph would remain as flat as it would otherwise be (something I do see as fairly important). They are independent, and there should be very little overhead involved, even when composing - avg could use the output from sum and count inline (with the downside of having to ensure sum and count are run first in the planner).

But we should talk later on this as you said.

[AndrewSisley]

I believed we agreed to defer the architectural decision on many vs one aggregate node(s) until we have at least one more node. I've added a comment on this in the countNode, planner and selectNode

[jsimnz]

Comments/responses all look good to me! Stoked to have the first aggregate in!