Add aggregate functionality for base layers

[thomasp85]

Fix #160

• basic infrastructure
• ensure aggregation happens with numeric pos1
• special case for range layers
• Consider segment
• update documentation
• What about non-positional aggregation

[teunbrand]

I'm excited for this! Don't let the nitpicky comments convince you otherwise

[teunbrand]

Thanks Thomas this looks to be in good shape to me now. There are a few things that we could pickup in a different PRs and one thing I'd like to have, but don't need to have.

Maybe for another PR:

• Since we're wiring now aesthetic_ctx to every stat, we should see if we can use it to throw better error messages from the stats.
• It might be interesting to investigate wether we could generalise the pattern of stat chaining you introduced here to arbitrary stat combinations in some way.

Like to have, not a blocker:

• I'd really like the aggregation parameter to follow the paths we've carved out for all the other parameters as well. The less custom logic the better. I understand it has more complex validation requirements, so what I'd propose is the following:
  • It gets included in the default_params of the affected layers
  • The ParamDefinition gets the string_or_string_array contraint, which is purely for type-checking the parameter.
  • The extra validation can happen in the setup_layer() method(s). Ideally it is parsed right there but I don't know how easy it would be to transfer the parsed result to the stat. (The setup_layer() may also need to be called in the validate.rs path, but that was an oversight of mine).

Most of the comments below this are minor. Nice work!

[teunbrand]

I think all tests we have for this FIRST/LAST thing are at the words of the query level. Maybe we should add a little test where this FIRST/LAST thing gets executed see if the resulting data is correct (just to watch for regressions).