* Make NewFromFloat respect the precision of the input
Restores the previous behaviour where input converted from float is truncated at the precision of the float.
The precision is depending on the actual value. Simply making it 15 digits would make it faster, but would in some cases lose some precision. So the code from the stdlib that does this calculation (very well) has been included.
Lots of good articles here: https://www.exploringbinary.com/decimal-precision-of-binary-floating-point-numbers/
Performance is around the same as the previous string roundtrip since it basically does the same, but allocations are a bit less.
`BenchmarkNewFromStringFloat` is the old method, `BenchmarkNewFromFloat` is the new.
```
BenchmarkNewFromFloatWithExponent-8 10000000 260 ns/op 174 B/op 4 allocs/op
BenchmarkNewFromFloat-8 2000000 744 ns/op 90 B/op 2 allocs/op
BenchmarkNewFromStringFloat-8 2000000 822 ns/op 258 B/op 6 allocs/op
```
* Update Sin/Tan/Cos tests.
* Added Atan method
* added sin and cos methods
* added tests for atan, sin, and cos
* tan method and test
* potentinal fix for './decimal_test.go:261:6: d declared but not used' error thrown by the tip version Travis CI tests + corrected comment in decimal.go
* Additional (and some breaking) tests for NewFromFloatWithExponent
* Addressing tests for NewFromFloatWithExponent
* Naming cosmetic correction
* removing unused code
* Improving FromFloatWithExponent
* Tests for exact float representation added
* Exact float representation in FromFloat
* Adding breaking test for NewFromFloat
* Fast path in FromFloat is unreliable, fixing it
* Addressing special meaning of zero exponent in float64
* NewFromFloatWithExponent: subnormals support
* NewFromFloatWithExponent: just a few additional test cases
* NewFromFloat: documentation update
* NewFromFloatWithExponent: optimization and some documentation
* NewFromFloatWithExponent: optimizations
* NewFromFloatWithExponent: optimizations
* Additional (and some breaking) tests for NewFromFloatWithExponent
* Addressing tests for NewFromFloatWithExponent
* Naming cosmetic correction
* removing unused code
* Improving FromFloatWithExponent
* Addressing special meaning of zero exponent in float64
* NewFromFloatWithExponent: subnormals support
* NewFromFloatWithExponent: just a few additional test cases
* NewFromFloatWithExponent: optimization and some documentation
* NewFromFloatWithExponent: optimizations
* NewFromFloatWithExponent: optimizations
Implementation of aforementioned methods applied an integer multiplier
to int part, and rejected the exponent. This did not work well for
positive exponent values - multiplier was supposed to be a non-integer
value less than 1, but was rounded up to it. This caused different
results for equal Decimal values like decimal.New(19, 1) and
decimal.New(1900, -1).
Now functions return the receiver if it represents an integer value.
This also reduces execution time for previously broken cases.
Performance and allocations not that good but can be optimized later.
RoundSwedish aka Cash/Penny/öre rounding rounds decimal to a specific
interval. The amount payable for a cash transaction is rounded to the nearest
multiple of the minimum currency unit available. The following intervals are
available: 5, 10, 15, 25, 50 and 100; any other number throws a panic.
5: 5 cent rounding 3.43 => 3.45
10: 10 cent rounding 3.45 => 3.50 (5 gets rounded up)
15: 10 cent rounding 3.45 => 3.40 (5 gets rounded down)
25: 25 cent rounding 3.41 => 3.50
50: 50 cent rounding 3.75 => 4.00
100: 100 cent rounding 3.50 => 4.00
For more details: https://en.wikipedia.org/wiki/Cash_rounding
BenchmarkDecimal_RoundSwedish/five-4 1000000 1918 ns/op 1164 B/op 30 allocs/op
BenchmarkDecimal_RoundSwedish/fifteen-4 300000 4331 ns/op 2940 B/op 74 allocs/op
* Corrected NullDecimal comment
Saying that NullDecimal is immutable is just incorrect, and we don't need
to duplicate the description of properties of a Decimal type here.
* Added UnmarshalJSON and MarshalJSON support for NullDecimal
* Added tests for JSON operations on NullDecimal
* Fixed mistakes in tests
This makes a noticeable difference when one is sorting a large slice
of decimals when most of them have the same precision, as it is saving
a lot of calls to rescale().
