[PATCH] replace float8 with int in date2isoweek() and date2isoyear()

Hi PG hackers,

I found suspicious use of float8 in date2isoweek() and date2isoyear(). In both
cases float8 is only used for storing the value, while the entire calculation
on the right happens in integers:

 float8 result = (dayn - (day4 - day0)) / 7 + 1;

At the end date2isoweek() returns `result' converted back to int:

 return (int) result;

float8 here is confusing and a bit slow.

I run a benchmark with optimization -O3, and found that using int is 3% faster:

BM_Float/1000/3/8_mean         5.12 ns         5.12 ns          100
BM_Int/1000/3/8_mean            4.95 ns         4.95 ns          100
BM_Long/1000/3/8_mean         4.96 ns         4.96 ns          100

Without optimization (-O0), speedup even better around 30%:

BM_Float/1000/3/8_mean         19.6 ns         19.6 ns          100
BM_Int/1000/3/8_mean             14.8 ns         14.8 ns          100
BM_Long/1000/3/8_mean          16.7 ns         16.7 ns          100

Additionally, as a paranoia measure I run a comparison test with the following
ranges: year={-100000,100000}, month={-100,+100}, day={-100,+100}.
As expected float and int did not produce any difference.

Attached patch replaces `float8 result' with `int result'.

I think there is no need in adding an extra test case here, because
date2isoweek and date2isoyear are covered by three regression tests:
* date
 SELECT f1 as "date",
     ...
     date_part('isoyear', f1) AS isoyear,
     date_part('week', f1) AS week,
     date_part('dow', f1) AS dow,
     date_part('isodow', f1) AS isodow,
 ...
     FROM date_tbl;
* timestamp
 SELECT date_trunc( 'week', timestamp '2004-02-29 15:44:17.71393' ) AS week_trunc;
* timestamptz
 SELECT date_trunc( 'week', timestamp with time zone '2004-02-29 15:44:17.71393' ) AS week_trunc;
---
Sergey