Introduce NonEmptyCollection

[serras]

As part of this Slack thread it seems that having a common parent for NonEmptyList and NonEmptySet could be quite useful, so we can have some common functions. For example, a function like toNonEmptyList can return a non-nullable type if we know that the receiver is NonEmptyCollection.

The definition of NonEmptyCollection looks as follows; those are all the functions I could think of which would benefit from the knowledge of something being non-empty.

public interface NonEmptyCollection<out E> : Collection<E> {
  override fun isEmpty(): Boolean = false
  public val head: E

  public operator fun plus(element: @UnsafeVariance E): NonEmptyCollection<E>
  public operator fun plus(elements: Iterable<@UnsafeVariance E>): NonEmptyCollection<E>

  public fun <B> map(transform: (E) -> B): NonEmptyCollection<B>
}

[github-actions]

Kover Report

File	Coverage [71.85%]
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/NonEmptyCollection.kt	45.45%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/NonEmptyList.kt	72.16%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/NonEmptySet.kt	76.19%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/raise/Builders.kt	72.46%
arrow-libs/core/arrow-core/src/commonMain/kotlin/arrow/core/raise/Raise.kt	75.00%

Total Project Coverage	49.87%

[nomisRev]

Looks really good to me! Thank you @serras 🙌 If I'm not mistaken the current suppression we have to do in value class will soon be fixed in Kotlin, so we won't need the suppression anymore.

Just one nit, if it's possible to define functions as methods I think we should prefer it. Results in better discoverability, auto-suggest, less imports, etc.

[nomisRev]

Fix compilation problems from Java

🤕 Again this issue. Did we ever report this to YouTrack? And unrelated, should we have some guidelines for generics and align all of them? 🤔

[raulraja]

Thank you @serras !