Rename bytesavailable (née nb_available) to nbytesavailable

[ararslan]

In #25634, nb_available was renamed to bytesavailable. However, it was noted that the n provided an important distinction, so this PR adds it for clarity, thus renaming bytesavailable to nbytesavailable.

This is technically a breaking change, code eagerly updated in the last few hours since #25634 was merged will get an UndefVarError from bytesavailable. I can add a defensive second deprecation if necessary.

[StefanKarpinski]

I don't really buy the need for the n – If it returned the bytes it would be called availablebytes instead of bytesavailable. Documenting that this returns the number of bytes and not a vector of bytes seems quite sufficient to me.

[JeffBezanson]

No strong opinion here. Either is fine with me.

[ararslan]

I also don't really care, but the proponents of n seemed to have a fair bit of support.

[nalimilan]

We seem to use the n prefix everywhere when a function returns a number of things, so why not here?

[bicycle1885]

If it returned the bytes it would be called availablebytes instead of bytesavailable

The n prefix would be a more explicit way to indicate that. Just adding a single byte is the simplest way and we already accept the convention in Base.

[bramtayl]

I wonder if there could be a list somewhere of "ok" abbreviations in Julia like number_of_ -> n. Even I'm willing to admit that number_of_available_bytes is a bit of a mouthful.

[ararslan]

Correct me if I'm wrong, but I don't think there's any strong opposition to adding the n; there seems to be mostly support and indifference. If that's the case then I think we should just go ahead with this. Is anyone actively opposed to adding an n?

[StefanKarpinski]

I don't really like the n in this name, but perhaps I'm the only one.

[JeffBezanson]

Triage is fine without the n.