feat(core): add `PMap2`, a parallel cmap prototype

[imrn99]

Implemented:

• vertex / sews are unchanged
• orbits (as POrbit2), this should eventualy be common code with CMap2
• the rest is implemented using new, non-mutable internals
• a From<CMap2> impl for PMap2

Skipped:

• generic attributes
• "side" structures such as the builder

part of #197

Necessary follow-up

• [x] Needs documentation
• [x] Other:
  • figure out vertex management
  • extract common code between the sequential & parallel impls
  • cleanup

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 84.60039% with 158 lines in your changes missing coverage. Please review.

Project coverage is 82.14%. Comparing base (ab03601) to head (e05579e).

Files with missing lines	Patch %	Lines
honeycomb-core/src/pmap/dim2/link_and_sew.rs	68.45%	88 Missing :warning:
honeycomb-core/src/pmap/dim2/io.rs	78.26%	30 Missing :warning:
honeycomb-core/src/pmap/dim2/basic_ops.rs	82.99%	25 Missing :warning:
honeycomb-core/src/pmap/dim2/utils.rs	0.00%	9 Missing :warning:
honeycomb-core/src/pmap/common.rs	0.00%	3 Missing :warning:
honeycomb-core/src/pmap/dim2/embed.rs	84.21%	3 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #198 +/- ## ========================================== + Coverage 81.67% 82.14% +0.47% ========================================== Files 38 47 +9 Lines 5342 6368 +1026 ========================================== + Hits 4363 5231 +868 - Misses 979 1137 +158 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[imrn99]

@cedricchevalier19 I'm not sure whether doing review is relevant during the implementation process since code will move very fast

[cedricchevalier19]

I think that rebasing this PR on a PR that just duplicates camp in map might make it easier to track changes due to parallelization.

BTW, why are you doing a separate data structure? Is it to benchmark the sequential behavior?

[imrn99]

I added a separate data structure because I wanted to keep the sequential one that has "no overhead" due to sync mechanism. In retrospect, this might be counterproductive since:

• we're aiming for parallel applications
• API of both structs would need to be kept similar in the context of a library

I think I'll redo the changes in a PR where I modify the original struct. I can benchmark the "overhead" by checking out to 0.6.0

[imrn99]

Closing this to reopen a cleaner PR with structure changes