Clarify why Arc is re-exported from std rather than modeled

[bkragl]

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sarsko]

I am fine-ish with the PR, but:

1. TODO is not resolved
2. I think maybe we'd want to be more elaborate with explaining Arc modeling and what we would support if we were to add it.

---

I think having a scheduling point for every Arc access is something which is hard to justify even for applications that really care about catching potential failing Weak upgrades (and I don't see when having a scheduling point would matter in any other case). My assumption is that the vast majority of such races will be found by having just the scheduling points we currently have.

Why are scheduling points needed at all if we have a scheduling point in upgrade?

---

The IMO real feature one can gain from modeling Arc is the ability to find Arc-cycles, which does not require a scheduling point addition.

The biggest con for owning Arc is that it makes onboarding a crate to Shuttle which uses non shuttlified crates more of a faff, since Arcs are pretty common in APIs.

If we add support for Arc and friends then there will probably be levels to the support. I assume the most common levels would be either full reexport (what we have now), or to reexport Arc from std, but to own Weak, and to own a version of Arc which provides downgrade taking std::sync::Arc as this (and so on for other functions on Arc), and Derefs to std::sync::Arc. This allows finding issues with Weak with minimal compatibility issues. The final level would be to provide a fully owned Arc and track ownership and be able to tell the user about them on shutdown.

All of this said, I have yet to be convinced that Arc/Weak modeling is something which is more than a nice to have.

[jorajeev]

I'm not a big fan of putting TODO/FIXME items in comments. How about just creating an issue for this?

[bkragl]

I still need to think a bit more about situations where modeling context switches in Arc and Weak would be needed/beneficial.

I agree that we can take the discussion about whether and how to model Arc to a dedicated issue. It would certainly be a breaking change though, and I also agree that it can make Shuttle onboarding of a codebase quite painful.

In any case, I think my updated comment is better than the previous one. So can we just merge it?