Bugfix linearsource scanspecv2

[LuisFSegalla]

While testing ScanSpecV2 I noticed that if trying to create an Acquire spec with fly=true and then tried making this into a scan and parsing the windows the positional values returned by the windows would be out of the expected boundaries of my motion spec. I believe this is to do with how the LinearSource is defined where we have it use the original length passed to it to define the step size, independent of the size of the index passed in setpoints.
This PR tries to address this by changing the way the step size is calculated and by adding some Unit tests to it.

Here's an example of the code I used to tests and find the initial problem:

from scanspec2.core import DetectorGroup
from scanspec2.specs import Acquire, Linspace, Static

det1 = DetectorGroup(1, 10, 1, 1, ["spec_det1"])
det2 = DetectorGroup(1, 1, 1, 1, ["spec_det2"])

spec = Acquire(
    spec=Linspace("x", 0, 10, 10), fly=True, detectors=[det1], stream_name="spec"
)
scan = spec.compile()

for window in scan:
    for axis in window.moving_axes:
        print(f"axis: {window.moving_axes}")
    for trig in window.trigger_groups:
        print(f"trig.detectors = {trig.detectors}")
        for pattern in trig.trigger_patterns:
            print(
                f"livetime = {pattern.livetime}\ndeadtime = {pattern.deadtime}\nrepeats = {pattern.repeats}\n"
            )
    for p in window.positions(1, None):
        print(f"pos = {p['x']}\nlen(pos) = {len(p['x'])}")

[coretl]

I'm sure we've got this helper somewhere else in tests/scanspec2 already...

[coretl]

The numbers make my head hurt. Please could you redo the test with Linspace("x", 11, 20, 10)

[coretl]

Then I would expect this to have size 11, and be [0.5, ... 10.5] as we are returning bounds rather than midpoints

[LuisFSegalla]

I don't understand why this would be the expected behaviour. Currently all the method does is shift the first point to be the equivalent to the first lower bound and then move all the subsequent points based on that, but it does not increase the expected number of points to also include the last upper bound.
That should be an easy enough change to make though if that's the intended behaviour.

[coretl]

This is the intended behaviour. The Spec should say "I want 10 points, each is 1s long". The positions function is asked "Give me points every 1s. That means it gets 11 points, from lower bound of the first point to upper bound of the last point. If it doesn't do this then we should modify it so it does.

[LuisFSegalla]

Okay, I'll push the changes that implement this logic.