Support anonymous fields in ftypes

[agspathis]

Adds support for anonymous struct/union/bits fields to struct/union ftypes, mirroring anonymous structures/unions of C11 and later. Besides their direct benefits, they also obviate the need to introduce tags for intermediate levels when generating ftypes from C types that utilize them.

Implementation outline: Anonymous fields are given a #t name (as opposed to #f of unnamed ones), which is then replaced by the list of subfield names accessible from the containing ftype. They're marked by the => keyword, as their functionality may be thought of as "field forwarding". The inspector has been adapted so that refing a field by name jumps to its level while registering a single down move (index-based access remains intact). Sample inspector session:

Transcript

Chez Scheme Transcript [Tue Apr 28 19:26:06 2026]
> (define-ftype Frob
    (struct [=> (union [=> (bits [a unsigned 2] [b unsigned 6])]
                       [=> (bits [A unsigned 6] [B unsigned 2])])]
            [=> [union [c char] [s short]]]))
> (define the-frob
    (make-ftype-pointer Frob (foreign-alloc (ftype-sizeof Frob))))
> (inspect the-frob)(ftype struct ...)                                                : p

(struct
  [=> (union
        [=> (bits [a 0] [b 50])]
        [=> (bits [A 8] [B 3])])]
  [=> (union [c #\à] [s -2080])])

(ftype struct ...)                                                : ftype
(struct (=> (union (...) (...))) (=> (union (...) (...))))        : p

(struct
  [=> (union
        [=> (bits [a unsigned 2] [b unsigned 6])]
        [=> (bits [A unsigned 6] [B unsigned 2])])]
  [=> (union [c char] [s short])])

(struct (=> (union (...) (...))) (=> (union (...) (...))))        : u
(ftype struct ...)                                                : set! c #\Q
(ftype struct ...)                                                : p

(struct
  [=> (union
        [=> (bits [a 0] [b 50])]
        [=> (bits [A 8] [B 3])])]
  [=> (union [c #\Q] [s -2223])])

(ftype struct ...)                                                : set! b 0
(ftype struct ...)                                                : ref b
0                                                                 : u
(ftype struct ...)                                                : p

(struct
  [=> (union [=> (bits [a 0] [b 0])] [=> (bits [A 0] [B 0])])]
  [=> (union [c #\Q] [s -2223])])

(ftype struct ...)                                                : ref 0
(ftype union ...)                                                 : p

(union [=> (bits [a 0] [b 0])] [=> (bits [A 0] [B 0])])

(ftype union ...)                                                 : set! A 80
Exception in ftype-set!: invalid value 80 for bit field of size 6
(ftype union ...)                                                 : set! A 40
(ftype union ...)                                                 : ref 1
(ftype bits ...)                                                  : p

(bits [A 40] [B 0])

(ftype bits ...)                                                  : u 2
(ftype struct ...)                                                : p

(struct
  [=> (union
        [=> (bits [a 0] [b 10])]
        [=> (bits [A 40] [B 0])])]
  [=> (union [c #\Q] [s -2223])])

(ftype struct ...)                                                : q

> (transcript-off)

Being new to the project, and given #1028, I wish to clarify that I haven't used any LLMs when preparing these changes.

[agspathis]

The ci (ta6le, ubuntu-24.04, test-more, more) test run failed after fixing ci (tpb, ubuntu-24.04, --pb --threads --enable-libffi, test-some-fast), which failed upon submitting the PR. However, since that test-more suite passed upon PR submission, the commit that fixed test-some-fast only touched ftype.ms, the failure is thread-related, and test-more passes locally, I think it might be a spurious failure. To avoid wasting resources, I'll await feedback for now and see whether the failure persists in future runs.

[mflatt]

I expect to take a closer look next week, but this seems like a reasonable addition and implementation approach on a first look.

[mflatt]

After taking a closer look and trying it out, this still looks good to me as a nice-to-have addition.

I'll give others a couple of days more to weigh in, but plan to merge soon.