uint32_t was getting promoted to signed int, which is not what we wanted...

Wow, clang has become good at generating warnings...

../../src/hb-common.h:349:29: warning: signed shift result (0xFF000000) sets the sign bit of the shift expression's type ('int') and becomes negative [-Wshift-sign-overflow]
  _HB_SCRIPT_MAX_VALUE                          = HB_TAG_MAX, /*< skip >*/
                                                  ^~~~~~~~~~
../../src/hb-common.h:93:20: note: expanded from macro 'HB_TAG_MAX'
 define HB_TAG_MAX HB_TAG(0xff,0xff,0xff,0xff)
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/hb-common.h:89:57: note: expanded from macro 'HB_TAG'
 define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint8_t)(c1))<<24)|(((uint8_t)(c2))<<16)|(((uint8_t)(c3))<<8)|((uint8_t)(c4))))
                                         ~~~~~~~~~~~~~~~^ ~~
../../src/hb-common.h:349:3: warning: ISO C restricts enumerator values to range of 'int' (4294967295 is too large) [-Wpedantic]
  _HB_SCRIPT_MAX_VALUE                          = HB_TAG_MAX, /*< skip >*/
  ^                                               ~~~~~~~~~~

And remove redundant implementations.

"Fixes" //github.com/harfbuzz/harfbuzz/issues/1191

#1196

Per https://github.com/Alexpux/MSYS2-packages/issues/163#issuecomment-73555971

As it may cause a race unrelated to the issue actually happened

As https://github.com/Alexpux/MSYS2-packages/issues/702

Using a hack...

text-rendering-tests test MORX-32 shows that for Insertion, an unset mark is treated
as mark set at 0.  This is unlike the Reordering lookup where un unset mark performs
nothing.

Fixes MORX-32.

Makes MORX-29, MORX-30, MORX-31 pass.

To help TSan.

A single find_package(harfbuzz) line in user code resulted in this loop
getting stuck when _harfbuzz_libdir_iter became "/".

See comment.

What were you thinking? ;)