make rand_tangent give only nice numbers

[oxinabox]

I don't think we ever cared about rand_tangent giving actual random valuis.
This rigs it so they are ones with fairly short decimal expressions.
(vs the standard for a Float of 19 charater and 42 characters for a Complex).

It is a bit of a balencing act between restricting the sample space, and getting things that are short.

I have 2 stratergies:

1. round(k*randn(x) sigdigits=n, base=2) this is I guess pretty general, but it resticts the space to z*2^-n.
2. rand(range) there are certain ranges of values that floating point can exactly represent. For example all Float's in Base can exactly represent -9:0.001:9 (but not -9:0.0001:9).

I use stratergy 2 for Float64 and ComplexF64 (the types we care about the most)
and strategy 1 for everything else.
Though perhaps I should just use randn(T) for everything else and not worry about it.
and/Or code the stratergy 2 for Float16, Float32, and the complex versions.

Contributes towards
JuliaDiff/ChainRulesTestUtils.jl#146

[oxinabox]

Example output

julia> rand_tangent(Random.default_rng(), [20,1, 1.0])
3-element Vector{Float64}:
 -1.85
  5.8
  6.37

julia> rand_tangent(Random.default_rng(), [20,1, 1.0 + im])
3-element Vector{ComplexF64}:
  1.3 + 4.7im
 -3.4 - 7.2im
  5.8 - 1.8im

julia> rand_tangent(Random.default_rng(), [20,1, 1f0])
3-element Vector{Float32}:
  3.1875
  7.25
 -1.3125

vs before

julia> rand_tangent(Random.default_rng(), [20,1, 1.0])
3-element Vector{Float64}:
 0.763615021012554
 0.18907650152439567
-1.145201534296794

julia> rand_tangent(Random.default_rng(), [20,1, 1.0 + im])
3-element Vector{ComplexF64}:
-1.8347206012984052 - 0.49090922332726283im
 0.3283012521981687 + 0.6142419220872114im
 0.4521831726291885 + 0.3891147996324198im

julia> rand_tangent(Random.default_rng(), [20,1, 1f0])
3-element Vector{Float32}:
 0.6569605
-1.1273828
-1.7002666

[mzgubic]

Looking forward to this being merged. Needs a version bump

[oxinabox]

This failure on SpecialFunctions.jl is real
https://github.com/JuliaDiff/FiniteDifferences.jl/pull/168/checks?check_run_id=2718333004#step:6:232

It is only equal to atol=1e-8 not atol=1e-9.
I am tempted top say we should just relax that before we merge this?