Replace the typed aggregate functions with simpler untyped ones

[tgoyne]

I was annoyed at having to update an error message in several different places and obviously the solution was to refactor everything to eliminate most of the duplication.

The API exposed by Table, Query and TableView for aggregate functions (e.g. minimum_int()) was a very poor fit for what Results wanted, and some gross metaprogramming was needed to deal with this. The one exposed by List and Set was a much better fit, so I made all of the types adopt that one. This is a breaking change for Realm Java, but it should be a very easy adjustment, and no other SDKs call these functions directly. There was also just generally a very large amount of duplicated code (List and Set had code which could live in Collection, Table and Query had almost-identical code, and Results and List duplicated some things).

The old aggregate functions had explicitly unspecified return values when there were no matching rows, but some tests still checked for a specific value. The aggregate functions now return Mixed() (i.e. null) if there are no matching values, and the tests have been adjusted to check for that. Other than that, all of the changes to tests are just non-functional syntax updates.

I added some basic benchmarks to make sure this wasn't going to slow things down. Int list/set got slightly slower due to the aggregation being so fast that the small additional fixed costs are measurable, but the absolute numbers are very small. The others stayed the same or got faster, sometimes significantly. Collections of objects got faster due to it no longer building a temporary table.

Collection	Row Count	Old	New	% Change
table	0	30.0474 ns	30.1747 ns	0
query	0	64.7815 ns	60.1893 ns	-7
tableview	0	63.8562 ns	59.7724 ns	-6
object list	0	3.1931 us	384.605 ns	-88
object set	0	3.70928 us	421.335 ns	-89
object dictionary	0	3.2056 us	372.53 ns	-88
int list	0	108.851 ns	202.466 ns	86
int set	0	111.507 ns	205.18 ns	84
int dictionary	0	268.587 ns	209.058 ns	-22
table	100	248.284 ns	255.725 ns	3
query	100	2.66283 us	2.50774 us	-6
tableview	100	2.67527 us	2.46436 us	-8
object list	100	10.878 us	5.05912 us	-53
object set	100	11.0564 us	5.14019 us	-54
object dictionary	100	19.7865 us	8.11521 us	-59
int list	100	345.519 ns	443.827 ns	28
int set	100	362.595 ns	444.451 ns	23
int dictionary	100	604.552 ns	574.125 ns	-5
table	1000000	2.22612 ms	2.23527 ms	0
query	1000000	142.77 ms	96.7282 ms	-32
tableview	1000000	143.09 ms	96.1786 ms	-33
object list	1000000	273.731 ms	107.992 ms	-61
object set	1000000	274.802 ms	107.579 ms	-61
object dictionary	1000000	2.9265 s	1.44572 s	-51
int list	1000000	2.10986 ms	2.13206 ms	1
int set	1000000	2.09435 ms	2.12917 ms	2
int dictionary	1000000	3.26774 ms	3.45399 ms	6

Dictionaries being massively slower than the other collections is fixed by #5780, which brings "object dictionary" in line with "object list".

[ironage]

Great improvement!

[ironage]

It may be unintuitive for users of this API to know that the sum of a float column is a double. This is something that was baked into the return type previously, but now has to be known. I think the tradeoffs are still heavily in favour of this change overall, but this is the cost of using a Mixed type for everything.

[tgoyne]

I don't like the sum of floats being a double for a few reasons, but I think in practice SDKs just switch on the Mixed's type anyway so returning any type in the Mixed probably just works out.

[ironage]

If SDKs are dynamically switching on the Mixed's type that would be ideal actually since it leaves room for us to change the underlying type in the future in a less breaking way. I vaguely recall some desire to use Decimal128 for average/sum of float/double, but I think that was stalled because of some non-trivial tradeoffs.

[ironage]

SO nice to finally get rid of these!