feat: add categories and send_at support

[watzon]

Summary

Adds support for SendGrid's categories and send_at API parameters, allowing emails to be organized by category for analytics and scheduled for future delivery.

Closes #13

Changes

• Add categories and send_at extension methods to Carbon::SendGridExtensions
• Consolidate all SendGrid-specific optional fields into sendgrid_options method for consistent handling
• Separate core email structure (params) from SendGrid API-specific options (sendgrid_options)
• Add comprehensive tests for both features
• Add EmailWithSendGridFeatures test fixture

Code Organization

Previously, SendGrid-specific fields were inconsistently handled between params (for asm, template_id, content) and extra_params (for categories, send_at). This has been refactored so:

• params: Core email structure only (personalizations, subject, from, headers, reply_to, mail_settings, attachments)
• sendgrid_options: All SendGrid-specific optional fields (asm, template_id/content, categories, send_at)
• deliver: Cleanly merges both hashes into the final JSON payload
  This improves maintainability and makes it clear where new SendGrid features should be added.

Usage

class WelcomeEmail < Carbon::Email
  def categories : Array(String)
    ["welcome", "onboarding", "transactional"]
  end
  def send_at : Int64
    1704067200_i64  # Unix timestamp
  end
  # ... rest of email config
end

[jwoertink]

Hmm.. Does it feel weird having some of the extra params added when building params and then some others added right before the delivery happens? Like, asm and template_id are already defined as extra params, but now where categories and send_at are added seem to be handled in a different area of the code. But maybe that's because of the level of the JSON where they need to be added? 🤔

[jwoertink]

I think overall the solution is fine. I'm just unsure if the organization of the code fits or would add more confusion to anyone looking over the code. What are your thoughts?

[watzon]

I'm good with changing it. I don't really care either way tbh. Just ran into some typing issues trying to do things that way initially and thought it would be cleaner. I think I agree though. Let me push a patch.

[jwoertink]

Nice! Yeah, the typing can get funky on these, but I think having all of this in one spot will make it easier for anyone else that wants to add a bit. Thanks for adding this in.

[watzon]

Of course. I'm using it so I figured I might as well contribute. Don't even know if I'll use these in the near term haha.