Add java priority queue, set, deque, collection coders

[kellen]

When using e.g. algebird PriorityQueueMonoid, scio needs to serialize java PriorityQueues. If Kryo is used, especially for small queues, there can be significant overhead.

Instead, this PR provides a PriorityQueue coder backed by a scala Ordering (as indeed the monoid is).

The coder must be created explicitly by the user so that they are asserting that the comparator of the original PriorityQueues and the reconstituted ones are the same. e.g.

implicit val pqCoder = Coders.jPriorityQueueCoder[T](ord)

@RustedBones Is there some trick I can use to get an error message when Coder[java.util.PriorityQueue[T]] fails to be derived (that's not just the generic implicitNotFound on Coder)?

[codecov]

Codecov Report

Attention: Patch coverage is 65.00000% with 7 lines in your changes missing coverage. Please review.

Project coverage is 61.43%. Comparing base (a1fce09) to head (92fad69).

Files with missing lines	Patch %	Lines
...com/spotify/scio/coders/instances/JavaCoders.scala	80.00%	3 Missing ⚠️
...ala/com/spotify/scio/testing/CoderAssertions.scala	0.00%	3 Missing ⚠️
...om/spotify/scio/coders/instances/ScalaCoders.scala	50.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5520   +/-   ##
=======================================
  Coverage   61.42%   61.43%           
=======================================
  Files         312      312           
  Lines       11104    11117   +13     
  Branches      757      753    -4     
=======================================
+ Hits         6821     6830    +9     
- Misses       4283     4287    +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[RustedBones]

I see we're also missing coders for java.util.Collection[T], java.util.Set[T] and java.util.Deque[T] which are available by default in beam

[RustedBones]

I think it would be better to create a coder instance, explicitly overriding consistentWithEquals instead of depending on a specific type for that reason

[RustedBones]

I recall we've been comparing underlying coder and value ordering here, but we've not done that for scala SortedSet nor PriorityQueue.

The drawback of such check is that we must give an ordering implementation that gives a stable equal after serialization (mostly by using object ordering).

[RustedBones]

shouldn't this be non deterministic too ?

[RustedBones]

Not really happy about this