Short-circuit return on zero input in cyl_bessel_y()

[WarrenWeckesser]

Over in #69, there were about 30 failures of the cyl_bessel_y() tests in the Windows CI job. This line

D:\a\xsf\xsf\tests\scipy_special_tests\test_cyl_bessel_y.cpp(42): FAILED:

appears 30 times in the log, and in each case the z input is 0. Apparently the culprit is somewhere in here:

xsf/include/xsf/bessel.h

Lines 963 to 970 in 33768a0

	if (sign == -1) {
	if (!detail::reflect_jy(&cy_y, v)) {
	nz = amos::besj(z, v, kode, n, &cy_j, &ierr);
	// F_FUNC(zbesj,ZBESJ)(CADDR(z), &v, &kode, &n, CADDR(cy_j), &nz, &ierr);
	set_error_and_nan("yv(jv):", ierr_to_sferr(nz, ierr), cy_j);
	cy_y = detail::rotate_jy(cy_y, cy_j, -v);
	}
	}

In this PR, I avoid that code by handling z=0+0j entirely in the first if-statemet where it checks for z = 0+0j. With this change, I don't see any of those cyl_bessel_y() test failures (but there are many others, so the Windows job still fails overall).

This change is not thoroughly checked, and is probably not the most elegant way to implement the calculation. I'm sure I'm duplicating functionality that should be in that code shown above, so I'm leaving this in draft status. I think this gets close to the correct behavior, so it might be useful for further investigation and debugging. Ideally the specific problem in the above code that occurs on Windows would be identified and fixed, and this PR closed without merging.

[WarrenWeckesser]

Edit: Moved comment to the top.