`complexity_iterator` is an iterator adaptor that's used to measure

the number of applications of a predicate/projection when there's no

predicate to measure (e.g. `ranges::find`).

`complexity_invocable` is an invocable adaptor that's used to measure

the number of calls to a predicate or projection. It differs from

`unary_counting_predicate` and `binary_counting_predicate` in two

ways:

- Most importantly, it isn't limited to predicates, and so works with invocables returning something other than Boolean values.
- It can store lambdas and works in constexpr contexts (this is secondary, but worth noting).

`test_algorithm` is an overload set that simplifies individual algorithm

test files. While working implementing `ranges::lower_bound`, I realised

that all test cases follow a strict pattern, for all implemented algos so

far (sometimes it can be simplified):

- set up subrange
- set up complexity instrumentation
- get iterator result
- check iterator result
- check complexity results
- reset subrange (if input iterators allowed)
- reset complexity instrumentation
- check range result matches iterator result
- check complexity results

A lot of this code can be factored out. In particular, this commit

abstracts away all the set-up and complexity-check stages. This in

turn elides the reset stages, individual leaving tests to focus on:

- get iterator result
- check iterator result
- check range result matches iterator result

An optional step 2.5 might creep in, where we check complexity results

for special cases (i.e. cases where that activate certain

optimisations).

The `test_algorithm` overload set isn't complete yet, but remaining

overloads can be added on an as-needed basis.

Depends on D105205.