Slightly optimise S_trie_bitmap_set_folded()

This static function in regcomp_trie.c evaluates UTF8_TWO_BYTE_HI(uvc)
twice, because a macro it calls uses the passed expression twice.
So calculate the value once into a local var.

Now, the compiler might already optimise this. But this commit may
or may not also have the (hoped for) side effect of shutting up a
Coverity warning.

The code is taking an 8-bit variant char, calculating what its upper
byte would be if converted to utf-8 (so in this case, only 0xc2 and 0xc3
are possible), then setting a bit in a trie representing this value. The
bit setting involves calculating the byte and bit offsets - the former
by doing >>3. But doing that shift on c2/c3 always gives the same
value, so Coverity is rightfully warning that UTF8_TWO_BYTE_HI(uvc) >> 3
is always constant.

By splitting that expression into two statements, maybe Coverity won't
notice. If it still does, at least this commit simplifies the code and
will make any eventual fix easier.

Here's the original Coverity report (it's complaining about the macro
which the previous commit subsequently turned into a static function):

>>>     CID 488118:    (CONSTANT_EXPRESSION_RESULT)
>>>     "(UV)(U8)(((UV)(*ch | 0) >> 6) | 192UL /* (U8)~(0xff >> 2) */) >> 3" is
0x18 regardless of the values of its operands. This occurs as a value.
1403                                         TRIE_BITMAP_SET_FOLDED(trie,*ch, folder);

regcomp_trie.c

@@ -534,7 +534,8 @@ S_trie_bitmap_set_folded(pTHX_ RExC_state_t *pRExC_state,
         /* store first byte of utf8 representation of */
         /* variant codepoints */
         if (! UVCHR_IS_INVARIANT(uvc)) {
-            TRIE_BITMAP_SET(trie, UTF8_TWO_BYTE_HI(uvc));
+            U8 hi = UTF8_TWO_BYTE_HI(uvc);
+            TRIE_BITMAP_SET(trie, hi);
         }
     }
 }