State every SQL aggregate with the MEOS function behind each of its roles

[estebanzimanyi]

The catalog gains the top-level list aggregates, read by parser/aggregates.py from the
deployed CREATE AGGREGATE statements: per aggregate its arguments, its result type and, for
each role it defines (transition, combine, final, serialize, deserialize, the roles chapter
18 of the MobilityDB manual names), the SQL function PostgreSQL calls and the public MEOS
function carrying that function's SQL signature, None for a function of PostgreSQL itself
(array_agg_transfn) or one no public MEOS function carries. Each role resolves as
PostgreSQL resolves it, by name over the argument types it is called with: the transition
function over the state and the arguments, the combine function over two states, the final
function over the state, with FINALFUNC_EXTRA's arguments where stated. The result type is
what the final function returns, else the state type. GENERATION.md lists the section.

Witness: the catalog carries the aggregates' machinery functions alone, each tagged with
the aggregate names it serves (sqlAgg), and no aggregate's own signature: nothing states
that tCount(tgeompoint) answers a tint, that temporal_tagg_finalfn finishes tCount, tSum,
tMin and merge alike, or which transition function an aggregate over a given type calls.

Why: a binding generates an aggregate the way it generates a function, from the catalog;
reading CREATE AGGREGATE or naming a result type itself is the hand-made code the bindings
are rid of. JMEOS builds the aggregates of Spark and Flink from this list.

Measured: over MobilityDB 985fdb26b7 the catalog states 349 aggregates, the count of the
portable naming plan, 97 of them with a public MEOS function for every role they define;
every other section of meos-idl.json is unchanged. pytest tests/ answers 468 passed and 11
skipped with MDB_SRC_ROOT set, test_aggregates.py's 9 tests among the passed.