feat: Clone for OpenOptions

[rbtcollins]

And perhaps more generally, some tokio glue would be nice. For File, tokio has a From implementation, but (somewhat obviously) no integration for these _at functions.

One path would be implement that here with a feature. Another would be to just make sure the types are friendly for doing that

when doing a naive shim layer, got this error

`*mut c_void` cannot be sent between threads safely
within `{closure@lib\testrepository_repository\src\io.rs:77:13: 77:20}`, the trait `Send` is not implemented for `*mut c_void`, which is required by `{closure@lib\testrepository_repository\src\io.rs:77:13: 77:20}: Send`rustc[Click for full compiler diagnostic](rust-analyzer-diagnostics-view:/diagnostic%20message%20%5B4%5D?4#file%3A%2F%2F%2Fc%253A%2FUsers%2Frobertc%2FDocuments%2Fsrc%2Ftestrepository%2Flib%2Ftestrepository_repository%2Fsrc%2Fio.rs)
io.rs(77, 13): within this `{closure@lib\testrepository_repository\src\io.rs:77:13: 77:20}`
io.rs(77, 13): this tail expression is of type `{closure@io.rs:77:13}`
io.rs(75, 9): required by a bound introduced by this call
mod.rs(1570, 12): required because it appears within the type `SECURITY_DESCRIPTOR`

[rbtcollins]

The error comes from Sacl and Dacl in SECURITY_DESCRIPTOR in OpenOptionsImpl on Windows. As Send and Sync are marker traits, this struct can never be safe to Send / Sync.

https://docs.rs/wnf/latest/src/wnf/security.rs.html#31-33 is an implementation that uses an opaque type; but this should still have Sacl and Dacl used by Windows, so it seems likely that an appropriate parsable descriptor could end up with cross-thread access through a pointer.

Clone is not implemented on SECURITY_DESCRIPTOR either.

Possibly switching to an external type and hoping would make sense.

Alternatively, making the OpenOptions methods consume the struct, or moving the non Send/Sync things to an Arc<Option> instead, might make sense.