[feature]: limit negative price rate spread

For rational economics, a node runner should want their asset buy price rate to be higher than their asset sell price rate. An asset buy price rate represents the number of BTC we need to pay for each asset purchased (the units are assets/BTC). Therefor, we always want to buy more assets for selling less BTC, hence the higher buy price rate. An asset sell price is the opposite. We want to sell less assets and buy more BTC since the units are still assets/BTC. So, we want a lower sell price rate.

Our absolute price rate spread can be represented as

PriceRateSpread=BuyPriceRate-SellPriceRate

and the relative price rate spread can be represented as

PriceRateSpread=(BuyPriceRate-SellPriceRate)/SellPriceRate

For rational economics, the PriceRateSpread should always be positive. However, right now in tapd and the price oracle server, we have the freedom to have a positive and negative price spread. A negative spread means the node will be trading at a net loss over time.

There are cases in the normal lightning network where one may want negative fees on the inbound side of a channel (https://docs.lightning.engineering/lightning-network-tools/lnd/inbound-channel-fees). However, these use cases seem only relevant to routing nodes. Right now, taproot asset nodes likely we be functioning as "edge nodes", so I'm not sure if there is a meaningful use case for a negative spread.

At the bare minimum, I think we should give a warning if someone is using a negative spread. Realistically, we should probably also require them to enable an allownegativepricespread option to allow this. We may just not want to make it an option at all though and not allow anyone to have a negative spread, this is up for debate. I'm not sure if this should be enforced in tapd or the price oracle, that is also up for debate.

The issue names tapd and the price oracle server as the entry points; start by tracing where BuyPriceRate and SellPriceRate are accepted and the spread is calculated. Resolve whether negative spreads should be warned about, gated by allownegativepricespread, or rejected, then define consistent behavior for both components.