Remove all logic related to wire tracks

[tdene]

When this library was first designed, wire tracks were considered an important factor.

Wire tracks stand out in classic prefix tree adder diagrams, where they are an important parameter and are clearly identifiable.
Furthermore, there is literature from the 1990s showing that wire tracks make a big difference when it comes to delay.

But the following questions exist:

• Are the parallel wires that appear in classic diagrams actually reflective of parallel wires that appear in the final, physical, layout?
• What actually causes a need for increased wire tracks, and what does that look like with generalized non-classic adder circuits?
• Can the effect of increased wire track requirements on final delay be predicted from these mathematical structures?
• Is the computation of this effect simple, and does it belong in this library?
• What is the actual effect of increased wire tracks in 2022?

As it stands, the method this library uses to identify a need for additional wire tracks and estimate its effect on the performance of the final circuit is unproven, inaccurate, and computationally slow.
This is in contrast to fan-out, whose computation is already necessary for other purposes, and which can be used to provide a decent estimate of final circuit performance through the method of logical effort.

Furthermore, functionality has already been added that allows for the delay estimation performed inside of this library to be outsourced to an external library using an optional parameter.

Given the questionable value of this computation, its effect on the performance of this library, and the need for continued maintenance, I would like to deprecate it.

[tdene]

@umarcor @macd @davidharrishmc @stineje Please advise.

[tdene]

"wire tracks" is a nebulous concept that is wrongfully extrapolated from faulty diagrams. While the physical effect is real, I currently have no way to quantify it. Run-time performance should not be destroyed by such a feature.