Fix: Better first_point fix

[arnaudon]

I fixed a mismatch of growth here: #75
but I now realise that this was adding 2 points at each growth iteration, not just when we bifurcate. This solution should be less disruptive.

More details on how this fixes asymmetry issue. I added a test that makes this morphology:

and we have the resulting synthetic apical without this, or #75 on the left, and with on the right:

the left morphology has no obliques on the left branch, because the right one had the firs bif, then was 1 micron ahead of the left branch, hence has always more probability to pick up the next bif, and this become exponentially the case.
Now we add a point also in the other branches, so they are all at the same path distance from soma when growing, ensuring equal probability for both apical stubtrees to bifurcate to obliques.

[codecov]

Codecov Report

Merging #96 (7a29457) into main (9d74824) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #96   +/-   ##
=======================================
  Coverage   97.76%   97.77%           
=======================================
  Files          39       39           
  Lines        2197     2199    +2     
  Branches      381      383    +2     
=======================================
+ Hits         2148     2150    +2     
  Misses         30       30           
  Partials       19       19           

Flag	Coverage Δ
pytest	97.77% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
neurots/astrocyte/space_colonization.py	94.32% <100.00%> (ø)
neurots/generate/orientations.py	100.00% <ø> (ø)
neurots/generate/tree.py	100.00% <100.00%> (ø)

[arnaudon]

so the change in neurots/astrocyte/space_colonization.py is the minimal thing I could find to stabilise the test between bb5/mac/github ci. I'm happy to have another solution, but I did not find one so far. If I understood well, the small numerical imprecisions due to numpy/scipy on different machines becomes large due to this normalisation of length vector when it is small (In the test, it can be 1e-7, so small deviations of 1e-10 or below get normalised and jump to 1e-3, which is at the edge of the accuracy of the test, and break them in this PR). It may also be beneficial to regularise this term in general, to prevent numerical instabilities, but I'm not sure on the repercusion of this rounding, and if there is a better way to do it in a least disruptive way