Turns out I don't need this to resolve CoreText optical sizing
issue after all.

https://github.com/behdad/harfbuzz/issues/360

New API:
hb_font_set_ptem()
hb_font_get_ptem()

Needed for hb-coretext optical sizing:
https://github.com/behdad/harfbuzz/issues/360

It doesn't always work, not part of FreeType, and we were not going
to expose it in the API anyway.  Can always be added later.

Also hookup to ValueRecord and Anchors.

Ouch!

Fixes https://github.com/behdad/harfbuzz/issues/255

New API:
- hb_font_get_nominal_glyph_func_t
- hb_font_get_variation_glyph_func_t
- hb_font_funcs_set_nominal_glyph_func()
- hb_font_funcs_set_variation_glyph_func()
- hb_font_get_nominal_glyph()
- hb_font_get_variation_glyph()

Deprecated API:
- hb_font_get_glyph_func_t
- hb_font_funcs_set_glyph_func()

Clients that implement their own font-funcs are encouraged to replace
their get_glyph() implementation with a get_nominal_glyph() and
get_variation_glyph() pair.  The variation version can assume that
variation_selector argument is not zero.

- use '-w' instead of '\<...\>' for check-header-guards
  grep manpage says these are the same

- put '-q' first in the grep options

- move VAR into hb-private.hh

- hb-font-private.hh - use [VAR] instead of [] for variable array

Hopefully makes clang build happy

Hopefully this wouldn't break any compiler.  There was some magic
moments to getting this to compile...

In anticipation of further changes.  No functional changes.

It makes the binary smaller AND faster.  Yumm!

Patch from Scott Fleischman.  Warnings were:

harfbuzz/src/hb-font-private.hh:121:42: Implicit conversion loses
integer precision: 'long long' to 'hb_position_t' (aka 'int')
harfbuzz/src/hb-font-private.hh:126:42: Implicit conversion loses
integer precision: 'long long' to 'hb_position_t' (aka 'int')
harfbuzz/src/hb-font-private.hh:400:85: Implicit conversion loses
integer precision: 'long long' to 'hb_position_t' (aka 'int')
harfbuzz/src/hb-ot-layout-common-private.hh:1115:37: Implicit conversion
loses integer precision: 'long long' to 'int'
harfbuzz/src/hb-ft.cc:421:97: Implicit conversion loses integer
precision: 'unsigned long long' to 'int'
harfbuzz/src/hb-ft.cc:422:97: Implicit conversion loses integer
precision: 'unsigned long long' to 'int'

This reverts commit 10f96462.

See discussion with Khaled Hosny on mailing list.  In short, since
integers here can be negative, and int division is "round towards
zero", proper rounding should take sign into account.  Just skip
doing it again, has been serving us well before.

Makes documentation / introspection easier.

https://bugzilla.redhat.com/show_bug.cgi?id=1001645

Doesn't matter for most users since they should be working in a
fixed sub-pixel scale anyway (ie. 22.10, 26.6, 16.16, etc).

https://bugs.freedesktop.org/show_bug.cgi?id=65544

Should give us some performance boost.