The Mul output is ready many gate delays before the MulAdd output,
so may be useful in some situations.

Not sure whether this is the best way to factor the code, so I'm not
going to PR this yet, but am pushing it so it doesn't get lost.

Tested with testfloat_gen -level 2.

Partially reverts f722163c

The reverted commit had the right idea but took a suboptimal approach.
Rather than one-hot-encoding the counter, we can reuse the divisor
register, thereby realizing the same circuit delay while eliminating
several flops.

Add AddRecFN and MulRecFN functional units

Ported from John Hauser's Verilog source
http://www.jhauser.us/arithmetic/HardFloat.html

Make DivSqrtRecFN_small tolerant to X-pessimism

In the recoded format, many bits are don't-cares for Inf, NaN, and zero.
Alas, taking advantage of that relies on sane processing of don't-cares,
which Verilog X does not have.

Luckily, in this case, the fix actually slightly reduces HW cost.

Revert bump.

port test from makefile to Scalatest 

Support publishing

Restore project (with sbt version)
Add required publishing information.

One-hot-encode the cycle number, so that the trial remainder doesn't
depend on the output of a decoder.  For a single-precision divider, this
increases the FF count from 100 to 122, but for a moderate frequency
target, it's roughly area-neutral and leaks less.

Might do this for other HardFloat modules over time, but this is the one
I need for the time being.