spec: phase out len on string values

[mvdan]

https://cuelang.org/docs/references/spec/#len says:

Argument type    Result

string            string length in bytes
bytes             length of byte sequence

Per @mpvl, we have wanted to remove len support for strings for a while. We borrowed this behavior from Go, although it doesn't make a lot of sense in general:

• len(bytes) is easy to understand, because it couldn't reasonably do anything other than counting bytes.
• len(string) is not as clear. Does it count bytes, characters/runes, codepoints? CUE users currently need to recall which it is.
• We already have clear and explicit ways to count runes: len(strings.Runes(string)).
• We could and should add a similarly explicit way to count bytes, such as strings.ByteLen(string), alongside the current alternative len('\(string)') to first convert a string to bytes.
• We could and should add other "length" std APIs, such as strings.RuneLen.

We should remove len(string) from the spec, and phase out its uses in CUE code by having cue fix rewrite it to strings.ByteLen(string). If a user intended something other than the number of bytes, they could swap ByteLen for a different API like RuneLen.

cc @myitcv @mpvl

[mvdan]

We'll add the new APIs and the cue fix in the upcoming release. We can remove support for the old behavior at a later point in time.

[mvdan]

Per Marcel, add an API in the strings package called Bytes to convert a string to a byte slice.

[myitcv]

One thing we need to consider here is how to constrain the length of something with a validator.

We already have https://pkg.go.dev/cuelang.org/go@v0.10.0/pkg/strings#MaxRunes and MinRunes, but that to my mind is unnecessary.

Because we could have something like list.Length which is a validator, that takes a cue.Value constraint such that:

import "list"
l: list.Length(>4 & <10)
l: [1,2,3,4,5]

This would then work for constraining the list of strings in terms of runes or bytes, or indeed anything else that can be made into a list.

The only problem is that list.Length is not, to my mind, clearly a validator. len() as a builtin function already exists. But perhaps this confusion between builtins functions that are validators and regular functions (that return values) is unavoidable.