Calling it on a special value now causes a failure, however `to_str_radix_special()` is provided which can be
used if those values are expected, and which returns a tupel to allow differentating them.
Also fixed all conflicting calls of the old functions in the rest of the codebase.
The set of string conversion functions for each float type now consists of those items:
- to_str(), converts to number in base 10
- to_str_hex(), converts to number in base 16
- to_str_radix(), converts to number in given radix
- to_str_exact(), converts to number in base 10 with a exact number of trailing digits
- to_str_digits(), converts to number in base 10 with a maximum number of trailing digits
- implementations for to_str::ToStr and num::ToStrRadix
- from_str(), parses a string as number in base 10 including decimal exponent and special values
- from_str_hex(), parses a string as a number in base 16 including binary exponent and special values
- from_str_radix(), parses a string as a number in a given base excluding any exponent and special values
- implementations for from_str::FromStr and num::FromStrRadix
- Moved ToStr implementation of unsigned integers to uint-template.rs.
- Marked the `str()` function as deprecated.
- Forwarded all conversion functions to `core::num::to_str_common()`
and `core::num::from_str_common()`.
- Fixed most places in the codebase where `to_str()` is being used.
- Added uint-template to_str and from_str overflow tests.
- Moved ToStr implementation of integers to int-template.rs.
- Marked the `str()` function as deprecated.
- Forwarded all conversion functions to `core::num::to_str_common()`
and `core::num::from_str_common()`.
- Fixed most places in the codebase where `to_str()` is being used.
- Added int-template to_str and from_str overflow tests.
They unify the different implementations that exists in int-template.rs, uint-template.rs and float.rs into one pair of functions, which are also in principle usable for anything that implements the necessary numeric traits. Their usage is somewhat complex due to the large amount of arguments each one takes, but as they're not meant to be used directly that shouldn't be a problem.
LinearMap is quite a bit faster, and is fully owned/sendable without
requiring copies. The older std::map also doesn't use explicit self and
relies on mutable fields.
