feat!: drop aggregations

[tim-hm]

Problem

The current aggregation feature in ⁠nildb presents several challenges:

• Security Risk: Aggregations can potentially be crafted to access data outside of a builder's authorized collections.
• Technical Complexity: Aggregations require reassembling secret shares before computation, which complicates the storage layer's responsibility.
• Performance: Queries can be demanding and inefficient over large, distributed datasets.

Goal

To simplify ⁠nildb's role into a pure, secure storage layer, we will remove the aggregation feature. This aligns with our strategy of delegating complex, multi-share computation to the upcoming ⁠nilcc service.

Acceptance Criteria

• All code related to the aggregation feature is removed from the ⁠nildb codebase.
• All related API endpoints are removed and documented as deprecated.
• The removal does not impact standard CRUD operations on collections.

• This breaking change is clearly communicated in the release notes.

[Davetbutler]

Drop or "hide", or "no big aggregations"...can we discuss this when we sync tomorrow?

In general, dropping is fine, but there may be some nuances around exactly what functionality a dev will have from querying POV

[Davetbutler]

Any plaintext data: I can filter any (most) ways I can think of. Exact match (bool, string, int), comparison (all values greater than X) etc