Type value changes & row type assertions

[Hydrocharged]

This PR has two primary goals:

1. All types now pass their values around in a form most suitable to that type.
2. Enforce that the aforementioned types are always passed to integrators, such that integrators do not need to do type validation on their end.

To elaborate on these points, some types already passed around values that were sensible and a best fit for that type, such as MEDIUMINT returning an int32. Other types, such as DECIMAL, passed around strings, which necessitated conversions for integrators to be able to properly persist the values. Not only that, there is currently no guarantee that a row's values each have their best fit type (a BIGINT can work with an int8, but it should be able to always expect int64). To make these guarantees, I'm adding a check at all GMS-integrator junctions that pass a sql.Row and verifying that the value types are exactly what that column expects.

This may have the side effect of changing the output of a SELECT statement for integrators. As a SELECT statement simply returns a sql.RowIter, additional logic will be needed to convert all values to their canonical MySQL representation. This can easily be achieved by passing all values through Type.SQL() before display.

[zachmu]

LGTM

My only real concern is places that are doing type assertions that could panic if they get a bad value from an integrator. I think I only saw this in Compare methods where the values being type asserted already passed through a Convert() call so should be safe, but be cautious about that.