Select link cwf bfw bug

[Jake-Moss]

Addressing the bug report raised in #493

Current thoughts are that the blending of the previous and current iteration is failing. The fix in 4894f61 doesn't seem to be enough, though it does extend the number of iterations where the results agree from 1 to 4.

[Jake-Moss]

Overall the root of the issue was that the select link wasn't taking into account the previous step directions in it's
calculations. In principle, the patch that modified the select to do just that should have worked, however, the matrix
that stored the previous step directions was allocated on the wrong object and, while the object lived the entire
duration of the assignment, the matrix was being zeroed at each iteration. I'd overlooked this as it did improve the
stability up to 4 iterations, but Jan pointed out to me that the beta's being used were 1.0 (and 0.0 respectively) up
until the 5th iteration where the step direction truly started to matter.

Another two bugs I found are patched.

1. The aon object was being leaked outside of the traffic class for loop, this meant that the last traffic class was
   being used for all select links analysis'. The aon objects are now stored and reused, this may increase memory usage
   during the assignment as GC can no longer clean the memory allocated by these objects up at the end of every AON
   assignment, instead it will at the end of all assignments.

2. As noted in the comment pre_previous_step_direction was being used in place of previous_step_direction.

[janzill]

lgtm, nice catch on the cfw pre_previous bug. To clarify, this should not influence results much because it only matters when running bfw and then only on the first bfw step-direction calculation after a cfw step (the latter has to happen when building up the previous and pre-previous step direction, so only once intitially or whenever the step-direction resets).