consensus: context cache for cumulative RCT outputs

[redsh4de]

What

Adds a in-memory rolling cache for cumulative RCT outputs, used by OutputDistribution.

Closes #635

Why

Public nodes that get frequent transaction requests benefit from this, as they don't have to rescan block_infos every time. Also curbs a potential DoS vector

Where

consensus/context:

• src/distribution.rs - new module: the cache, the request handler, the slicing/delta math, and the per-block RCT count.
• src/lib.rs - new OutputDistribution request/response. numb_rct_outputs field on NewBlockData.
• src/task.rs - build the cache at startup, push on update, truncate on pop, serve the request.

types:

• src/types.rs - new OutputAmount. OutputDistributionInput is now generic over it, and its rct_start_height field is gone.
• src/blockchain.rs - renamed the OutputDistribution read request to PreRctOutputDistribution (now pre-RCT only), added CumulativeRctOutsInRange.

storage/blockchain:

• src/service/read.rs - renamed the output_distribution handler to pre_rct_output_distribution and narrowed it to pre-RCT amounts, added cumulative_rct_outs_in_range.

binaries/cuprated:

• src/rpc/handlers/shared.rs - decode the amounts into OutputAmount, route to the context.
• src/rpc/service/blockchain.rs - removed the old DB output_distribution wrapper.
• src/rpc/service/blockchain_context.rs - new output_distribution wrapper (routes to the context).
• src/blockchain/manager/handler.rs - set numb_rct_outputs on the new block.

How

The cache keeps the cumulative RCT output counts per block, built once at startup from the database and kept up to date by the context task - each new block pushes its total, a pop truncates from the end (same as the difficulty and weight caches).

Requests are answered by slicing the cached prefix: the amount 0 (RCT) distribution comes straight from the cache for any (from, to) range. Pre-RCT amounts are forwarded to the database and merged back in request order.