[5.8][stdlib] Expose index rounding entry points

[lorentey]

Cherry picked from #62798.

These simply expose the preexisting algorithms that String views use to implicitly round indices down to the nearest valid index within the view. (Or, in the case of the encoding views, rounding down to the nearest scalar boundary.)

Being able to do this as a standalone, explicit, efficient operation is crucial when implementing some String algorithms that need to work with arbitrary string indices.

This PR exposes these operations as unstable, underscored entry points. Ideally these would get upgraded to public API soon, but first I'd like to prove these have the right semantics by experimenting with using them in their underscored form.

rdar://101652714

[lorentey]

@swift-ci test

[stephentyrone]

This all looks basically fine; can you explain what considerations lead to marking them all @aeic?

[lorentey]

The implementations for rounding indices within the Unicode scalar, UTF-8 and UTF-16 views were already fully transparent within the .swiftinterface. The new entry points simply make these accessible to clients outside the stdlib, and it felt better not to limit their availability.

An alternative way to achieve the same would be to use @_backDeploy @inlinable. As of 080d850, this is now a supported combination, but I don't feel comfortable using it yet in the stdlib. I think it could be an option on main, though.

The index rounding entry points for character views weren't previously exposed, so the new methods for those views come with 5.8 availability.

[stephentyrone]

Yeah, to be clear, I have no objection to marking them aEIC, I just want to understand the rationale.

[lorentey]

I don't really have a strong opinion here -- @_aeic is simply my default choice in this case.

Letting index rounding deploy back to earlier stdlibs when possible is the most developer-friendly option. The rounding implementations are already inlined into clients via the regular indexing APIs, so emitting them has no real client-side code size cost. (This also makes the inability for stdlib updates to change the behavior of these entry points in existing binaries largely moot -- that concern is valid, but it applies far more strongly to the normal index APIs.) Marking the new entry points aeic also leaves the door open to (eventually) replace these with non-underscored public API, without having to deal with an ABI symbol -- if we choose to go that way.