Improves aggregates over decimal translation for PostgreSQL

[alex-kulakov]

Since Npgsql library does not provide ways to read full range of PostgreSQL decimals but reads only the values that fit to .NET decimals, we have to change cast result type to be compatible with .NET, which may cause some issues later but there is no other suitable option at the moment which would make sense. Options recommended in some official answers don't fit and ridiculous, and the client library maintainers don't see this inability to read whole spectrum of supported values as bug/issue/design flaw which should be fixed/improved.

As a try to somehow predict possible precision and scale of result type, a guessing algorithm introduced which, in case of aggregate over decimal expression, visits the expression and gathers precision and scale of the fields used in the expression and then, and if it is possible, computes scale and precision based on gathered data. In case of complex expressions, containing other numeric types, the algorithm assigns some predefined precisions and scales for them for better result parameters estimation, it doesn't take into account mathematical operations though, which would add complexity and make expression visiting slower.

Later, on translation of providers and if aggregate expression is not a single column but complex expression, another assumption made. Maximal .NET precision (28) is used for database type precision and scale defines with a bit bigger resolution to attempt to not lose result of AVG and SUM operation. What's left from increasing scale goes basically to floor part of result value.

For aggregates over simple column no cast applied, precision and scale will be this implicitly declared by the column settings on server side.