Account for node size in branch lengths

[dan-knight]

if (!nodes && length.from.node.edge) {
    tree <- adjust.branch.lengths(v,tree,node.radius, scale1);
    }

This does not always calculate accurate lengths for the second length column (when provided). I suspect it has to do with converting back from scaled (by scale1) units.

I removed this functionality temporarily until this is resolved. I also removed the nodes and length.from.node.edge parameters from SRCGrob, as they can be added back in without losing backwards compatibility.

[whelena]

Fixed on hwinata-issue-sweep (342014e).

The second length column was never computed incorrectly, and the problem was not the conversion out of scale1 units — that round-trip is algebraically exact, verified across 13 configurations with asymmetric scale1/scale2, user scale arguments, polygons and varied plotting directions.

The actual defect: adjust.branch.lengths() reserved node.radius * node.size at each end of an edge, but add.node.ellipse() draws the node at node.radius * node.size * (1 + 0.2 * nchar(label)) so the label fits inside it. Every node therefore overlapped the end of its own edge and absorbed part of it, making the drawn branch shorter than the value it encodes. Same symptom as #103, whose fix (79f21df) handled the node.size half and missed the label scaling the same function applies.

Measured shortfall:

case	branch shortfall
default 1-char label, node.size 1	−20.7% / −4.1% / −2.1%
node.size 3	−62% / −12.4% / −6.2%
6-char labels	−92% / −20.9% / −10.5%
2nd column, scale1/scale2 ≈ 8.5	−8.8% at node.size 1, −26.4% at node.size 3

That last row is why this was reported as a second-length-column bug. The reserved radius is expressed in scale1 units, so the same absolute shortfall reads much larger against the second y-axis whenever scale2 < scale1. The second column was not computed differently; it magnified a shared error.

Node geometry now lives in get.node.ellipse.size() / get.node.ellipse.ar() in R/add.nodes.R, shared by the ellipse grob and the length adjustment so the two cannot drift apart again. Also renamed the column adjust.lengths() uses to identify the longest branch — it was relying on grep('length', ...) column ordering and was only correct by accident — and guarded the length2.c assignment against deleting the column.

This also closes #107. The new tests in tests/testthat/test-issue-21.R measure drawn segments against the drawn node ellipse rather than against stored coordinates, which is the "deeper test utilities to measure grobs in relation to one another" that #107 asked for. They fail 12/29 against pre-fix code with exactly the predicted shortfalls.