feat: use typescript to ensure there's email or id for contacts.get

[gabrielmfern]

This pull request changes the code for contact's get to only allow for one of email or id in the types, but also leaving it at runtime while we don't have the error on the API.

Before this we had both email and id as optional fields that could be paseed onto get. Which meant that we had to error when both were missing, which meant things weren't really type-safe and only failed at runtime, instead of when running tsc or seeing LSP diagnostics.

The types still allow for including both email and id, but only one of them can be truthy (not undefined, or null) at once.

[CarolinaMoraes]

I really liked your approach! I have a consideration about it:

How do you see the gap between TypeScript users x vanilla JS users here? Because TypeScript users will get compile-time errors for wrong usage, while vanilla JS users will be able to hit the API with wrong data and the message returned can be a bit less clear

This is the returned message when the user only passes audienceId if we don't validate at runtime at all

contact: {
  data: null,
  error: {
    statusCode: 422,
    message: 'The `id` must be a valid UUID.',
    name: 'validation_error'
  }
}

(I'm not saying we shouldn't go forward with the increased type-safety approach you provided, I'm more interested in knowing if you see value in having a hybrid alternative here)

[gabrielmfern]

@CarolinaMoraes the message is definitely less clear, but could that be more something to improve on the API side instead of on the SDK's side?

[CarolinaMoraes]

@gabrielmfern

I thought about your comment and went to check what can be done on the API side so that your PR can be approved. We still don't have this error being thrown for Zod union validations, but I think it can be implemented
I would just advise us not to change this runtime validation yet, as we currently don't have this same error code implemented for contacts on the API -- so, SDK users that are already expecting a missing_required_field might get a frustrating experience

[gabrielmfern]

@CarolinaMoraes good point, let's leave the runtime checking for now while we don't have it on the API and remove it later on!