feat!: Reason about Send/Sync-ness of types and change Rcs to Arcs

[jeeeesper]

This is an attempt to make the library a bit more usable in a multi-threaded setting. I started to replace Rc<T>s with Arc<T>s where the wrapper type is supposed to be Send and/or Sync [1]. Of course, since we work with raw C-pointers and htslib in the background, it is quite the task to actually reason about thread-safety, so the assumption so far is that the C methods behave reasonable™. I need to mention that I am not very familiar with the underlying C code. So far, this PR also does not nearly solve all the problems related to thread-safety, frankly, it might introduce more. For example, I added Send/Sync implementations for some Header types, the soundness of which I have not really verified.

This all is motivated by the use of the library in my own multi-threaded program, and of course is therefore biased to what would be convenient for me (Send/Sync on Header or Reader/Writer types for example.) For getting a Send/Sync Reader/Writer, it is of course also possible to just create Wrapper types.

Maybe this will inspire some people to continue working on this, or I will do once I find the time. Maybe, this will even revive the discussion about how to solve this issue in general. I am very open to suggestions/discussions.

There are multiple issues that are mentioning this, most importantly maybe #293 .

[1] The performance penalty is, in my opinion, absolutely tolerable and greatly outweighs having to deal with segfault when doing something "simple" as using a parrallel iterator.

[coveralls]

Pull Request Test Coverage Report for Build 20367476991

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 34 of 35 (97.14%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.005%) to 81.869%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/bam/header.rs	0	1	0.0%

Totals
Change from base Build 20367318966:	0.005%
Covered Lines:	2786
Relevant Lines:	3403

---

💛 - Coveralls

[johanneskoester]

The lint is already fixed in the master branch.
I think this should be pretty complete for now. I will merge it into master. In case I missed something, please let me know or directly create a follow-up PR.
Thanks a lot!!