Make Violation trait sealed for compiler exhaustiveness checks

[suin]

Could you add sealed keyword to Violation trait for the sake of type-safety of client code?
Compiler warns that match-case statement is not safe on code like:

@tailrec
def flattenViolations(treeViolations: List[Violation], flatViolations: List[Violation] = List()): List[Violation] = {
  treeViolations match {
    case Nil => flatViolations
    case (violation: RuleViolation) :: violations =>
      flattenViolations(violations, flatViolations :+ violation)
    case (violation: GroupViolation) :: violations =>
      flattenViolations(violation.children.toList ++ violations, flatViolations)
  }
}

[error] /...[snip].../AccordExtensions.scala:19: match may not be exhaustive.
[error] It would fail on the following input: List((x: com.wix.accord.Violation forSome x not in (com.wix.accord.GroupViolation, com.wix.accord.RuleViolation)))
[error]     treeViolations match {
[error]     ^

So client code has to have default case, even if it is unnecessary like:

  treeViolations match {
    case Nil => flatViolations
    case (violation: RuleViolation) :: violations =>
      flattenViolations(violations, flatViolations :+ violation)
    case (violation: GroupViolation) :: violations =>
      flattenViolations(violation.children.toList ++ violations, flatViolations)
    case _ => throw new RuntimeException("Invalid state") // Unnecessary case if `Violation` class were sealed.
  }

[holograph]

Not a bad idea, though it's worth noting that one of the reasons it's not yet the case is because the result model is still WIP (obvious case that isn't covered is #21, and there may be ramifications following #36). That being said, changes are going to breaking anyway, so your suggestion still seems appropriate.

[holograph]

I'm a little concerned that this may break client code extending Violation, but since I can't imagine anyone actually doing that I'm going ahead with this. If anyone has feedback to the contrary, I'd love to discuss your use-case.