Let #[Enum] interfaces have methods

[linabutler]

One thing that I've found super helpful when working with enums with associated data is being able to define getters and predicates on them. Here's an example inspired by mozilla/application-services#5346 (comment):

dictionary SuggestionDetails {
    string title;
    string url;
    string? icon;
};

// Each suggestion type has a common set of details, and additional fields specific to that type.
#[Enum]
interface Suggestion {
  Shopping(SuggestionDetails details, string full_keyword, string advertiser);
  Education(SuggestionDetails details, string full_keyword);
  Wikipedia(SuggestionDetails details);
  Weather(SuggestionDetails details, CurrentConditions current_conditions, Forecast forecast);
};

I'd love to be able to define methods on Suggestion like:

• SuggestionDetails details(), a getter that extracts the details from each variant.
• boolean is_sponsored(), a predicate that checks the suggestion type and returns whether it's sponsored (Shopping) or not (Education, Wikipedia, Weather).

UniFFI doesn't allow doing that yet, but @mhammond's follow-up comment (mozilla/application-services#5346 (comment)) inspired me to file a ticket to see if it could! 😊 As a workaround, we can add extensions in hand-written Kotlin and Swift files, but I wonder if we could push this down into UniFFI.

(It would be even nicer to make these readonly attributes instead of methods—I think all our target languages support that? Python has @property, Kotlin has getters, Swift has computed properties, Ruby's getters are regular methods—but that might be too tricky).

┆Issue is synchronized with this Jira Task
┆Issue Number: UNIFFI-236

[Sajjon]

@linabutler nice! I also had the idea id of generaring computed properties in the land of Swift, but we probably need to be able to chose if a no arg method should be exported as computed property or method, since at least in Swift there is an informal rule that computed properties SHOULD be constant time.