IA32: Add __divmoddi4/__divdi3/__moddi3 gcc intrinsics replacements

[pbatard]

• When carrying out signed int64 division, GCC on IA32 automatically generates the intrinsics calls above because it expects linking with libgcc, which we obviously don't link against.
• This results in undefined reference errors when linking code that carries out long divisions.
• Fix this by adding these missing calls in ia32/math.c.
• Note that, for the time being, and to avoid potential conflicts with existing workflows, we limit this to MinGW compiler usage, as this is where we are seeing the issue. But we can easily remove the MinGW guard if regular gcc users report that they need those as well.
• Also, with respect to AI usage disclosure, the assembly code was generated by Claude.

[ncroxon]

Have you been testing this change?

[pbatard]

Hold on on this patch.

My assertion was that we're not linking with libgcc, but we actually are with:

gnu-efi/apps/Makefile

Line 78 in 3cf072a

LOADLIBES += $(LIBGCC)

and

gnu-efi/Make.defaults

Lines 327 to 329 in 3cf072a

	ifneq ($(ARCH),arm)
	export LIBGCC=$(shell $(CC) $(CFLAGS) $(ARCH3264) -print-libgcc-file-name)
	endif

And indeed, if I try to carry out IA32 long division in the gnu-efi apps, there's no issue.

I guess I should probably be able to link with libgcc in my project as well, which is much better than trying to redefine the gcc intrinsics in gnu-efi.

I'll keep this PR opened for now, but please don't act on it. If I manage to sort it out on my end, I will close it.

[pbatard]

Closing this PR, as I can indeed link with libgcc in my project like gnu-efi does. The only gotcha, for those interested, is that you do want libgcc.a to appear last in your list of libraries, as if you have any -l<somelib> statements after, the gcc intrinsics provided by libgcc.a somehow fail to resolve...