multi card support

[vhnatyk]

Describe the changes

This PR enables multi-gpu support

Linked Issues

Resolves #135

[jeremyfelder]

We should add documentation about how to use multiple devices. It wasn't clear to me at first how a Device slice could be set on anything but the default device.
Its also unclear how set_device() works with multithreading

[DmytroTym]

Maybe because setting a new device in a context automatically invalidates the context and setting a different stream invalidates the context if this stream was created for a different device, we should re-design or at least encapsulate the context somehow? Though I guess it's a breaking change technically

[DmytroTym]

Really like the idea of one CPU thread = one device. Maybe we'll have some inconveniences integrating into third party applications that already have their own multithreading but stand-alone it seems very elegant and natural to me.

The only thing I don't really like is adding new functions for context and config creation that accept device_id. I feel like we can always just infer device id using cudaGetDevice especially considering that we want device id to be set once for the entire duration of the CPU thread. More generally, I feel the need to push back against all non-essential free floating functions being added to the public API. As discussed with @ChickenLover at some point, it feels like once there are too many of them - we should create a struct, a trait etc.

[DmytroTym]

@vhnatyk okay last counter-proposal. Recently we moved get_default_ntt_config into Rust, this allowed us to actually implement it generically. Using this function seems to me much better than the free-floating functions as before. Can we from now on use NTTConfig::default_config and NTTConfig::default_config_for_device, not add get_default_ntt_config_for_device and schedule get_default_ntt_config for deprecation? Maybe the same can be done for the DeviceContext struct, not sure why would I put a free-floating function there, for consistency with configs I guess, but now since we added another initialiser I would definitely prefer DeviceContext::default_context and DeviceContext::default_context_for_device.

[DmytroTym]

lgtm