Imagine we have the following buy orders:
[100 100 100 10 10 10]

Current increase logic:
[100 100 100 10 10 30]
[100 100 100 10 30 30]
[100 100 100 30 30 30]

New increase logic:
[100 100 100 30 10 10]
[100 100 100 30 30 10]
[100 100 100 30 30 30]

The concept for valley and neutral modes is "always increase as far as
possible".

To avoid excessive orders replacements increase orders by `1 +
increment` steps as in other modes.

Previous limiting was wrong, turning mountain into buy slope when sides
are imbalanced.

In dd12ef1 we completely turned off
orders increases for situation when partially filled order detected on
opposite side. This is not very-well suited for ocassionally-running
workers. This is also helps to prevent excess spread tradings on huge
price drifts.

In new version additional_reserve factor is added to reserve some more
funds than currently needed, this would be useful for valley-like modes.

There is a race condition possible when partially filled order was
further filled before new order actually replaced them. We can just
ignore such case and continue to work.

When increasing orders with imbalanced sides, use at least 15% increment
steps.

Instead of dumb-replace closest partially filled order, check whether
opposite-side order is also partially filled. This condition is clearly
indicates a spread trade. If that condition is not met, just allocate
funds to increase orders sizes as usual.

When increasing orders sizes, do not try to dumb-replace partially
filled orders too. Instead, check available funds and currently
remaining order amount. Put increased order only if we have enough
balance. Otherwise, just keep it.

Instant fill check in place_closer_order() should be performed only when
place_order=True. We don't need this check if we are not actually
placing an order but just want to obtain amount and price for the next
order.

The error occured when bootstrap was turned off but there is no opposite
orders. Add check for such situation. Bootstrap should not be turned off
if there is no opposite orders.

Replace closest partially filled orders only when excess funds was allocated.

Operational depth limit allows to keep only N buy or sell orders and
adding more orders if needed (price movements).

Reasons for having depth limit:

* Decrease strategy maintenance time
* Reduce blockchain overhead by decreasing transactions count
* Increase initial order placement time

Closes: #386

Update readme

There was a bug causing additional virtual orders placement after
initial boostrap.

Previous fix in bd39424 solved not all
occurances of the issue. The problem condition may also occure when
opposite side was reached a range bound, thus opposite_oeders will be
None.

Reported by El Stone on telegram.

The problem was that x% adjustement on FOO:BAR market did not produced
the same result as -x% adjustement on BAR:FOO market.

Updated implementation doing more aggressive offsetting of center price.

This version of asset offset calculation was originally proposed by El
Stone on telegram. This is a slightly refactored version.