More FFI APIs

[Manishearth]

Unfortunately the temporal_core stuff breaks all the duration APIs, and I don't understand what it's doing. I wrote this PR before that change, help updating it to work with Duration appreciated.

In general I don't think it's a good idea to have two separate Duration types with differing APIs. Opting in to features might enable new APIs, but it's not kosher to disable APIs that way, which seems to be the case here.

[nekevss]

I'll take a look at it ASAP

[Manishearth]

useful bit of context: I wrote this on the plane and rebased it later

[nekevss]

The quickest way to fix this issue is to opt out temporal_capi from the default features or remove the default feature from temporal_rs entirely and have the "full" feature be opt-in.

But as mentioned in #165. The wrapper concept around core might need to be looked at again.

[Manishearth]

@nekevss I don't think opting in to a feature should ever break code?

[Manishearth]

For example, I'm having code break because YearMonth uses the core duration. From what I can tell this core vs builtin split doesn't quite work: Core contains types which reference each other, and only some of them are wrapped in builtin and reexported, so you get a broken mix of things.

error[E0308]: mismatched types
   --> temporal_capi/src/plain_year_month.rs:108:36
    |
108 |                 .subtract_duration(&duration.0, overflow.into())
    |                  ----------------- ^^^^^^^^^^^ expected `Duration`, found `temporal_rs::Duration`
    |                  |
    |                  arguments to this method are incorrect
    |
    = note: expected reference `&temporal_rs::temporal_core::Duration`
               found reference `&temporal_rs::Duration`
note: method defined here
   --> /home/manishearth/dev/temporal/src/builtins/core/year_month.rs:139:12
    |
139 |     pub fn subtract_duration(
    |            ^^^^^^^^^^^^^^^^^

[Manishearth]

I've done the fix to make this landable, but this situation isn't ideal.