[8.0] fix significant digits lost on unit conversion in _compute_qty_obj

Steps to reproduce:
1. Create a product. Check purchase ok, set procure method to buy, and unit of measure to 'inch'. Add a supplier for procurements and set quantity on hand to 1.969.
2. Create a reordering rule for the product. Set min to 2, max to 0 and multiple to 6.
3. Run `Compute Stock Minimum Rules Only` (or `Run Schedulers` as it also calls `_procure_orderpoint_confirm`) at least 3 or more times.

Current behavior:
A procurement order is created each time `Compute Stock Minimum Rules Only` is run. The first procurement order is for a quantity of 6.000 (due to reorder rule `qty_multiple`) since the quantity on hand of 1.969 is less than the reorder rule `product_min_qty` of 2. This is expected. The issue is that **each subsequent time** `Compute Stock Minimum Rules Only` is run another procurement order is created for a quantity of 0.090.

Expected behavior:
Running `Compute Stock Minimum Rules Only` multiple times one after the other should only generate one procurement order (the first one in this case for qty 6). The calculations done in `_compute_qty_obj` are losing significant digits when doing the unit conversion even when `from_unit` and `to_unit` are the same. It is this loss of significant digits and the use of `ceiling` that seem to be causing the current unexpected behavior.

I don't see any reason we would want to round the `amount` (at line 185) when we divide qty by `from_unit.factor`. We want these significant digits to be available for generating the product of `amount` and `to_unit.factor`. Unless someone can offer a reason to use `ceiling` here, it seems all we would need to do at this point is round the new `amount` as per `to_unit.rounding`. Making these changes results in the Expected behavior of the reordering rules as they get applied by `Compute Stock Minimum Rules Only`.

If there is a better way to handle this please advise.

May be related to #3350 and #2854.
Tested after at least some of the changes made in #2976 and #2672 appear to have been forward-ported to 8.0. Issue still exists.