Use __builtin_ctzll on GCC/Clang and _BitScanForward/_BitScanForward64 on
MSVC to speed up Table_map_iterator::next_bit(), up to 3 times in benchmarks

Removed Field_map, since it was used only in a single function.

Fixed is_indexed_agg_distinct(), since it relied on initialization of
Bitmap in constructor.

GCC crashes during compilation, on a code fragment that was added  to
workaround code generation bug on GCC.

To fix, I randomly moved pragmas around, which seems to make GCC happy.

Older GCC generates SSE instruction on not-128-bit-aligned data in
Bitmap<128>::buffer

Workaround by forcing GCC not to use SSE on Bitmap<N> template.

* Update wrong zip-code

With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around
ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays
valid still)

With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type
anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers
which make Bitmap invalid, when it is memcpy-ed/bzero-ed.

The problem in 10.4 is that there are many new key_map members, inside TABLE
or KEY, and those are often memcopied and bzeroed

The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality.
pointers/heap allocations are not used anymore.