Fix parsing of unusual Alignment values in ASS style definitions

Fix parsing of unusual Alignment values in ASS style definitions

Handle large and negative values except INT32_MIN like VSFilter.
This avoids both overflow and inconsistent internal state.

This fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=523.

VSFilter handles INT32_MIN like a mix of \an1, \an2 and \an3:

  * Vertical alignment is bottom.
  * Lines within the event are center-aligned.
  * Without \pos or \move, the center of the event is aligned
    with the right edge of the screen minus MarginR.
  * With \pos or \move, the left edge of the event is aligned
    with the position point.
  * Without \org, the rotation origin is aligned
    with the horizontal center of the event.
  * (With \org, the rotation origin is as specified.)

If we wanted to emulate this in libass, the cleanest way would be to
introduce a new horizontal alignment constant for this purpose that
would be used only for ASS style definitions with Alignment INT32_MIN.
This commit makes no attempt to do this and instead arbitrarily picks
\an2 for style definitions with Alignment -INT_MAX-1, which equals
INT32_MIN if int is int32_t. The fact that int is platform-dependent
is one of the reasons for this. We could change Alignment to be int32_t
instead of int for perfect VSFilter compatibility, but the same applies
to many other fields that currently use platform-dependent types.