Test nb::int_(double).

[1uc]

This commit adds tests that demonstrate that nb::int_(x) does not create an integer, but instead it creates a float. There's three new tests:

• test_21_f (f because float) that shows that when converting from nb::float_ the issue isn't present.
• test_21_g (g is after f) that nb::int_(1.5) creates a Python float and not an int. The two Python drivers for the test fail as follows:

>       assert type(t.test_21_h()) is int
E       AssertionError: assert <class 'float'> is int
E        +  where <class 'float'> = type(1e+50)
E        +    where 1e+50 = <nanobind.nb_func object at 0x7a1c53febcd0>()
E        +      where <nanobind.nb_func object at 0x7a1c53febcd0> = t.test_21_h

>       assert type(t.test_21_g()) is int
E       AssertionError: assert <class 'float'> is int
E        +  where <class 'float'> = type(1.5)
E        +    where 1.5 = <nanobind.nb_func object at 0x756d659efbc0>()
E        +      where <nanobind.nb_func object at 0x756d659efbc0> = t.test_21_g

• test_21_h (h for huge) that check of something like nb::int_((long) x) isn't an ideal workaround.