Add a mechanism for selective style overrides

This adds 2 new API functions:

  ass_set_selective_style_override()
  ass_set_selective_style_override_enabled()

They can be used to force dialog text to use a specific ASS_Style. It
uses a fuzzy heuristic for that, and the quality of results may vary.
It does style overriding selectively and tries not to override things
that need explicit styling. The heuristic for that isn't set in stone
either, and can change with future libass versions.

Closes libass#88.
parse_tag: split \fscx, \fscy, \fsc
parse_tag: merge \fs+, \fs-, \fs
Move (r)skip_spaces to ass_utils
Parse override tag arguments exactly like VSFilter 2.38

Also replace strtocolor in ass_utils with string2color
from ass.c, because that is more useful everywhere now.
Introduce ass_drawing_add_chars for adding a whole string at once
Require closing '}' for override tags

Like VSFilter. '{' without a following '}' is just text, though
in vector drawing mode it still delimits individual drawings.

This also lets us nicely avoid '\0' hacks
in the \t override tag handler in parse_tag.
parse_tag: remove unnecessary malloc
Use ass_drawing_add_chars for vector drawings

This not only provides a performance improvement but also
conveniently fixes the following issue: we used to interpret
backslash-escapes in vector drawings, but we shouldn't.
Simplify drawing text assignment
Implement LayoutResX/LayoutResY

This allows ASS scripts to be independent from video resolution.

Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
Do font supersampling the VSFilter way

To avoid jerking when font size scale is animated caused by grid
fitting, we intentionally request an overly large font size from
FreeType and downscale the outline afterwards.

Currently this large font size is fixed at 256.
This commit changes it to 64 times the actual wanted font size,
which is what is used by VSFilter. The advantages are:
  * Compatibility with VSFilter.
  * Support for font hinting, even if at 64 times the size.
    Knowing this coefficient, scripts can compensate
    for it by correspondingly decreasing \fs values.

This improves upon commits 7af7801 and c207000.

The drawback is that jerking is reintroduced when an mplayer
window with libass EOSD is resized. Jerking could be avoided
by scaling \fscx and \fscy instead of \fs. Pro: this would make
the exact look of the font completely resolution-independent.
Con: this would play badly with font hinting. In any case,
this commit makes no attempt to do this.

ensure_font_size, unused since 7af7801, is removed in favor of
clipping the font size just before passing it to FreeType, as
discussed in issue #46. The mysterious height*2 check is dropped.
Scale \fscx/\fscy instead of \fs from storage to display resolution

This prevents jerking on media player window resize.
Make fix_outline always produce the correct final color

Whenever a glyph has a border, the original glyph's own ASS_Image
is applied on top of the border's ASS_Image. Let's mathematically
devise such alpha values for the border image that the resulting
colors exactly match (modulo rounding) the colors produced by a
hypothetical ASS_Image that contains both the glyph and the border.

Let a_i be the opacity of a single pixel within an ASS_Image,
where i is either g for glyph or o for outline (border). Further,
let A_i be the opacity and c_i the color of the entire ASS_Image.

Think of a_i as the _area_ covered by the glyph/border,
measured in pixels. We have 0 <= a_g <= a_o <= 1.
We also have 0 <= A_g, A_o <= 1.

We need a background color. Let's denote it as c_b. The background
color includes any effects from applying the shadow of the glyph.

The final color we want to achieve is:
  * on the area covered by the original glyph,
                                       A_g c_g + (1 - A_g) c_b.
  * on the area covered by the border, A_o c_o + (1 - A_o) c_b.
  * on the remaining area,             c_b.
Averaging the color over the pixel's area gives:
           a_g  (A_g c_g + (1 - A_g) c_b) +
    (a_o - a_g) (A_o c_o + (1 - A_o) c_b) +
      (1 - a_o)  c_b

The color we actually get after blending the border with the
background and then blending the original glyph with the result is:
        (A_g a_g) c_g +
    (1 - A_g a_g) ((A_o a_o) c_o + (1 - A_o a_o) c_b)

We want to replace a_o in the actual color's expression with a
value that makes it match the expected color. Let's call this value
a_o'. Equating both expressions and solving for a_o' gives:
       A_o (c_o - c_b) = 0 and a_o' does not matter
    or A_g a_g = 1 and a_o' does not matter
    or a_o' = (a_o - a_g) / (1 - A_g a_g)

In the A_o (c_o - c_b) = 0 case, we can always pick an a_o' that
satisfies one of the other two conditions. Effectively we can
ignore the first case altogether.

A_g a_g can only equal 1 if A_g = a_g = 1. Since a_g <= a_o <= 1,
a_o must also be 1. As it happens, libass already handles this case
separately: as a precaution, it checks that a_g < a_o and sets a_o'
to zero if this condition fails to hold. This works fine, so let's
retain this behavior.

This commit makes libass use the solution formula from the third
case to calculate a_o'. To enable this, the opacity of the original
glyph is passed to fix_outline and outline_to_bitmap3. Generated
bitmaps depend on it, so glyphs with different primary color alpha
are now distinguished by the bitmap cache. The calculation itself
is performed exactly and rounded correctly (half towards +infinity)
using only integer arithmetic.
Omit fully transparent glyphs from non-opaque-box shadows

If there is an outline around the transparent glyph,
the shadow is supposed to be a copy of this outline.

This completes the fix made in commit f9283004,
which covered the case where there is no outline.

Fixes issue #70.
Make fix_outline more correct in presence of blur

Blurred alphas are not coverage values. The area that is not
covered by the original glyph is a mix of the border and the
background, governed by the blurred border opacities. To get
an exact result, we need to integrate the blurred opacities
on fragments of pixels that exclude the original glyph (or,
equivalently, on fragments that are covered by it, as these
fragments are complementary). Unfortunately, we are unable
to do that.

Give up on exact values and treat each border pixel
as a uniform average that directly scales with area.
In fact, blur itself already does this.

Note that we can now get non-zero opacities even when the
glyph's coverage is larger than the border's uncorrected
opacity.

Writing and solving equations like before, we obtain:
       A_o (c_o - c_b) = 0 and a_o' does not matter
    or A_g a_g = 1 and a_o' does not matter
    or a_o' = (a_o - a_g a_o) / (1 - A_g a_g)
Handle the first case like the third,
and handle the second case by setting a_o' = 0.

The observable difference for non-blurred bitmaps
was not large in my tests, but the code is simple,
so the exact non-blurred calculations are retained.