Rework @fieldParentPtr to use RLS

[jacobly0]

Passing in the ParentType as the first argument to this builtin turned out to not be sufficient because the alignment of the return parent pointer can not be perfectly recovered from the alignment of the passed in field pointer. Since the most reasonable way to communicate the desired alignment is to pass in the desired pointer type instead, this PR first changed the first argument from a struct/union type to a pointer to struct/union type. However, since this results in a builtin with the first argument matching the type of the result, it becomes a candidate for RLS, and so next this PR removes the argument entirely. At this point, it becomes an open question whether @fieldParentPtr should implicitly perform an @alignCast or whether it may be necessary to write add an explicit @alignCast call to get a naturally aligned result. I chose to require an explicit @alignCast to be able to see how it feels and because it will be easier to remove the requirement in the future than to introduce it. So far, I haven't found it to be unusually restrictive to require the explicit @alignCast, so that behavior remains. This PR also contains a C backend rewrite to fix bugs uncovered by the frontend change.

Migration Guide

const parent_ptr = @fieldParentPtr(Parent, "field_name", field_ptr);
↓
const parent_ptr: *Parent = @fieldParentPtr("field_name", field_ptr);
or
const parent_ptr: *Parent = @alignCast(@fieldParentPtr("field_name", field_ptr));
depending on what parent pointer alignment the compiler is able to prove. Note that the second form is more portable, since it's possible for the @alignCast to be needed for some targets but not others.

Closes #18023
Closes #14904

[ethernetsellout]

Note that the second form is more portable, since it's possible for the @alignCast to be needed for some targets but not others.

This seems like a reason to revert to the previous behavior, with the implicit cast. Otherwise you get code that looks portable but actually isn't.