fix CostMatrix for trivial routes with oneways

[nilsnolde]

fixes #4538

it's a pretty obnoxious problem: if 2 locations in a matrix snap to the same edge but that edge is a oneway in target -> source direction, we'd still determine a simple trivial route for source -> target. that is because in CostMatrix::SetTargets() we record the opposing edges of the correlated target edges for the labels/adj list. however, we don't check if those opposing edges are even allowed for our costing. in loki they are discarded because of the oneway, in thor we just silently add them.

I tried multiple solutions on this, but the only one which worked for all cases (also non(-pseudo)-trivial ones) was to record in SetOrigins/Targets whether the correlated edge (or its opposing) are allowed. I do that via BDEdgeLabel::path_id_, which isn't used in CostMatrix of course and now only used in the connection check when we find we're attempting a trivial route.

and sorry for the cleanup with variable renaming, it's easier to follow now and more consistent. I flagged all actual changes!

[kevinkreiser]

totally cool to do renames/refactors but it would be much more convenient for review to separate them too, though a pain in the butt i totally get it. anyway i looked at the two spots where you set/check the cached allowed value via the path_id overload. i guess re-evaluating allowed wouldn't be a good option since it requires getting the edges again which we dont have at that spot in the code. we could just keep another vector of this info and look it up in that. we do a moderate amount of overloading of things in the databuilding and its always confusing but i get why you did it, its certainly the most convenient place.

other than that i looked at one tiny bit of refactoring to use the cached graphtileptr in the opposing functions (because this is a change and because its often a place where ive made mistakes). anyway that looked good but i didnt look at any of the other refactoring because it was too much 😄