Partial ABI compatibility validation implementation

[sproctor]

What kind of change does this PR introduce?

Very incomplete implementation of using Kotlin's ABI compatibility validation plugin. Before I went to implement this, I wanted to get your thoughts.

This could go in buildSrc and be applied to each module that should maintain ABI compatibility.

Motivation

While contemplating some changes that would change the ABI, I thought it might be good to have a validation procedure in place.

[jan-tennert]

Yea looks good to me at first glance. @SupabaseInternal marked methods/classes etc are still relevant for binary compatibility, no? I mean ignoring these would make sense but they still are relevant.

[sproctor]

Technically, yes, they are relevant. If they're called from an inline function, then they need to be kept. If they're just called from another module, then I think that's an ABI breaking change that is ok, because I don't think supporting mixed versions of modules is worthwhile. Probably best to include them in the API anyway so any changes are intentional.

I'm a bit overwhelmed with other work right now. It might take me a week or two to get back to this.