Move last-hop route handling to the common "normal" hop codepath

When we handle the unblinded last-hop route hints from an invoice,
we had a good bit of code dedicated to handling fee propagation
through the (potentially) multiple last-hops and connecting them to
potentially directly-connected first-hops.

This was a good bit of code that was almost never used, and it
turns out was also buggy - we could process a route hint with
multiple hops, committing to one path through nodes A, B, to C,
then process another route hint (or public channel) which changes
our best path from B to C, making the A entry invalid.

Here we remove the whole maze, utilizing the normal hop-processing
logic in `add_entries_to_cheapest_to_target_node` for last-hops as
well. It requires tracking which nodes connect to last-hop hints
similar to the way we do with `is_first_hop_target` in
`PathBuildingHop`, storing the `CandidateRouteHop`s in a new map,
and always calling `add_entries_to_cheapest_to_target_node` on the
payee node, whether its public or not.

Author: TheBlueMatt