Issue 5790: Rational conversion clean-up

https://sourceforge.net/p/testlilyissues/issues/5790/

This review squashes these commits that mainly clean up initialization
and conversion of Rationals, though there are some minor bug fixes.

For most of the unit tests which are disabled here, I have fixes that
I am holding back for the sake of simplifying this review.

1: create unit tests

2: remove unused infinity_rat

3: use default copy-construction and assignment

4: disambiguate integer conversions
   and fix sign when initialized by unsigned integer

5: disable implicit conversion to bool

6: discard r.to_double () in favor of static_cast<double> (r)
   This helps developers avoid question-raising statements like this:
       Real x = r.to_double ();
   and encourages statements like this:
       auto x = static_cast<Real> (r);

7: disable implicit conversion to double
   This helps emphasize places where exactness might be lost.

8: to_int () becomes trunc_int ()
   and returns I64 like num () and den ().

[lemzwerg, 2020-02-25 05:54:18]

Very nice, thanks!  LGTM.

[hanwenn, 2020-02-25 08:07:14]

LGTM

(I wonder if we should bite the bullet and use uint64_t iso. U64.)

[dak, 2020-02-25 10:35:56]

On 2020/02/25 08:07:14, hanwenn wrote:
> LGTM
> 
> (I wonder if we should bite the bullet and use uint64_t iso. U64.)

Just for the record: the big bullet would be a Simple_smob wrapper class around
Guile's rational data type.  Showstopper in the current setup: Moments in data
structures contain rationals and would need to get heap-marked, but the Midi
data structures are not memory-managed by Scheme.  Even the non-showstopper
parts would be quite a bit of work.  Workaround/migration strategy could be a
variant adding itself into a doubly-linked list of data structures to be marked
outside of the normal Scheme mechanisms and handled by construction/destruction
and reference counting, with the obvious memory overhead.

The alternative would be to base our implementation of rationals not on U64 but
on GNU mp.  There is


 -- C Function: void scm_to_mpz (SCM val, mpz_t rop)
     Assign VAL to the multiple precision integer ROP.  VAL must be an
     exact integer, otherwise an error will be signalled.  ROP must have
     been initialized with ‘mpz_init’ before this function is called.
     When ROP is no longer needed the occupied space must be freed with
     ‘mpz_clear’.  *Note (gmp)Initializing Integers::, for details.

 -- C Function: SCM scm_from_mpz (mpz_t val)
     Return the ‘SCM’ value that represents VAL.

but that sounds like slowing down things more.  Maybe we should collect this
JFTR in some actual issue.