Incorrect total circs for current/previous year in Item Status

Working branch user/jeffdavis/lp2018534-numeric-circbyyr fixes the issue by forcing the staff client to treat circbyyr years as numbers:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp2018534-numeric-circbyyr

Test plan:

1. On a server with a Postgres 14 database, go to Item Status and scan an item with at least one circ for the current year.
2. Click Detail View. "Total Circs - Current Year" shows 0 circs.
3. Apply the fix.
4. Repeat steps 1-2. "Total Circs - Current Year" should now show the correct circ count for this year (and the previous year).

Kudos to Jason Boyer for noticing that Postgres changed the return type for EXTRACT from double precision to numeric; this appears to be what introduced the problem. The return type was changed in PG14, so Postgres versions up to and including PG13 will be unaffected by this bug.

Jeff,

Thanks, that looks like a perfectly wonderful fix for the issue. I'll commit this unless someone beats me to it.

For future-us, the background/root-cause of this is that Postgres's NUMERIC type is only limited by the general field size limitations of the backend (generally 1GB worth of ASCII characters), whereas other number-ish types (INT, BIGINT, etc) have upper and lower limits that allow us to map them to normal number-like types in the languages EG is implemented in. So, for NUMERIC, we map to the language-native string type to avoid rounding, overflow, or the like.

In this particular case, an alternate solution would be to cast the column's type to, say, INT, and then it would be number-ish in the intermediate JSON. It wouldn't be crazy to do that in addition to Jeff's fix, also, since we know the range of reasonable values for this column/field.

As promised, I've picked this to master for 3.11 inclusion. Thanks, Jeff!

Also pushed into the branches fro 3.10 and 3.9.