Improve lower_bound(min_price) performance

[abitmore]

User Story
When calling something like an_index::lower_bound(price.min(a,b)) as well as upper_bound(max_price), step into lower_bound(), when the pointer is on a record with price(a,b), 128-bit computations will occur, see

bitshares-core/libraries/chain/protocol/asset.cpp

Lines 50 to 51 in cb0dbb8

	const auto amult = uint128_t( b.quote.amount.value ) * a.base.amount.value;
	const auto bmult = uint128_t( a.quote.amount.value ) * b.base.amount.value;

IMHO the 128-bit computation is unnecessary in this case since operator<() will always return true (or false when in another direction). If we can find a way to avoid the computation without much overhead, we may be able to get better performance. Need benchmark.

Related to #1094. Part of #982.

Impacts
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

Additional Context (optional)
Add any other context about your request here.

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[pmconrad]

Assuming the index is organized as a tree, any lookup (or insert) operation will have to traverse the tree and make a comparison at each node. In the case of lookup by price, a large fraction of these comparisons will be decided only by looking at the asset IDs, which is cheap. Comparisons on the numeric parts are unavoidable in the general case.

In the specific case of min/max lookups, comparisons could be avoided if all elements for a particular asset pair were stored in an index of their own. In that case, the min/max lookup would be equivalent to begin/end of the pair-specific index, which should work without comparisons.
The question is if this would pay off. There certainly is some potential, seeing that mix/max lookups are used quite often by the market engine.