Make the timers crate follow submodule design

[fitzgen]

The crates/timers crate should follow the submodule design that we came up with in #27 and are formalizing in #34.

That is:

• Move the callbacks-based APIs into a callbacks submodule
• Move the futures-based APIs into a futures module
  • Make the cargo dependency on the futures crate optional
  • Only expose the futures submodule when the futures feature is enabled

[Pauan]

I don't like having a feature which has the same name as a package dependency (i.e. the futures crate), so I think we need to change the feature name.

[OddCoincidence]

Wouldn't the full name be gloo-futures though? This seems fine / non-ambiguous to me.

[Pauan]

No, this proposal says that the feature will be called futures (which conflicts with the futures dependency).

It's unusual to prefix a feature like that, but I'm not against gloo-futures, as you say it is unambiguous.

[OddCoincidence]

Oh sorry, I misread your original comment (assumed you were referring to the crate name). Isn't having a feature named the same as package dependency relatively common? e.g. I see features called serde quite often.

[Pauan]

@OddCoincidence I was referring to both the crate name and the feature name (since they're currently the same). Sorry I wasn't clear enough!

It may be common, but it's also wrong (or at least heavily problematic): #38 (comment)