fix(ffi): don't panic when running into an unknown membership state

[bnjbvr]

Fixes #1254. This adds a bandaid in the form of converting Into impl to TryInto, and then will happily ignore errors in multiple places; unknown states are logged in warnings, so we can still get some information about it, would they become an issue in the future.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.76%. Comparing base (a901506) to head (56c7f00).
Report is 7 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4144   +/-   ##
=======================================
  Coverage   84.76%   84.76%           
=======================================
  Files         269      269           
  Lines       28848    28848           
=======================================
+ Hits        24453    24454    +1     
+ Misses       4395     4394    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[poljar]

I suppose it's better than a panic.

[bnjbvr]

There's no way to expose the private custom variant's content anyways, right?

[bnjbvr]

It was actually quite simple to handle custom memberships; not sure how the apps will like it? cc @stefanceriu @jmartinesp

Re-requesting a review, since there's a non-trivial change in there.

[stefanceriu]

Turns out you need to name that field but otherwise it shouldn't be a problem for the app
error: UniFFI only supports enum variants with named fields (or no fields at all)

[poljar]

I think that this is not the intended way, as the _Custom variant is hidden and instead you're supposed to use the catch all, but then other known states won't be handled (there are none other known states but the enum is non-exhaustive).

I think we can live with that despite the intentions of Ruma.