Fix discarded variable sized string segment patterns not being disallowed

[LilyRose2798]

This fixes the issue where the following code snippets with discarded variables in utf8 bit array patterns are allowed to compile:

let assert <<_:utf8>> = <<>>

case <<>> {
  <<_:utf8>> -> todo
  _ -> todo

When the variable is not discarded, the compiler already correctly disallows the pattern, as variable length string matches are not allowed for bit arrays:

let assert <<x:utf8>> = <<>> // correctly gives a compiler error

The fix is just this single line change:

- Pattern::Variable { .. } if segment_type.is_string() => {
+ Pattern::Variable { .. } | Pattern::Discard { .. } if segment_type.is_string() => {

Credit to Julian (@julian.nz) in the Gleam Discord server for finding this issue.

[lpil]

Thank you! Could you update the changelog bug fix section please 🙏

[LilyRose2798]

I've updated the changelog as well as rebasing onto the latest main commit (apologies for all the messy force pushes, I'm pretty new to doing pull requests and not sure of all the best practices for this).

[lpil]

Thank you!

Force pushing is good by me 👍

[lpil]

Looks like there's a snapshot that needs to be accepted!

[LilyRose2798]

Hopefully it should work now? I ran cargo insta review and accepted the snapshot.

[LilyRose2798]

Well there are more checks passing now, but still some failing. Looking at the big block of code in the output for them, it seems like the code contains references to _:utf8 which may be the reason they're now failing. Not sure why cargo test runs successfully on my machine (linux) but not on those checks.

[GearsDatapacks]

Looks like it's failing from this line of the stdlib: https://github.com/gleam-lang/stdlib/blob/main/src/gleam/bit_array.gleam#L70
On Erlang, _:utf8 is the same as _:utf8_codepoint, so I guess that's why the issue wasn't caught until now.

[LilyRose2798]

Ah, thanks for the input. So I'm assuming the stdlib may need to be updated to use utf8_codepoint instead of utf8 in that location then before this PR can be merged?

[GearsDatapacks]

Seems like it yes. In that case would this be considered a breaking change? Or will we treat it like a bug which was never intended?