Find ways to slim down provider binary sizes

### What problem are you facing?
This issue doesn’t significantly impact us, but we noticed that the container images generated from Upjet-based providers (specifically the AWS provider in this case) are quite large.

For reference, the S3 image is 768MB:

>REPOSITORY TAG IMAGE ID CREATED SIZE
>xpkg.upbound.io/upbound/provider-aws-s3 v1.20.1 0ea4c3c5e06f 17 seconds ago 768MB

I then performed a raw go build over the cmd/provider/sqs zz_main.go file, which resulted in a binary that's 1.1GB in size:

> -rwxr-xr-x@ 1 jakub staff 1.1G Mar 5 15:58 sqs

This build is based on the c47300 commit. For comparison, the Go 1.24 binary is around 18MB.

### How could Upjet help solve your problem?
We could find ways to slim down the generated binary, which would reduce the size of the container images, saving storage space and speeding up deployments.

Additionally, the build time seemed quite long. Optimizing the binary size could likely reduce build times significantly.