GUI: fix BMP font_size parse for V1/V2/V3.0/V3.2

[JIRA] NA
[JIRA TYPE] Bug-Introduced-Critical
[Introduced by] NA

[Issue description]
The BMP font header used a compile-time ENABLE_FONT_V3_TYPO switch to
decide font_size width/offset, but the on-disk format (V1/V2/V3.0 vs
V3.2) is a runtime property. With the switch on, every legacy font had
its font_size read as a uint16 at offset 5-6 instead of a uint8 at
offset 6, yielding huge bogus sizes (e.g. size24 read as 6145).

[Issue reproduction]
1. Build with ENABLE_FONT_V3_TYPO=1 (default).
2. Load any pre-V3.2 BMP font (e.g. SourceHanSansSC_size24, ver 3.0.0).
3. Text fails to render: lib lookup by size never matches and the
   non-crop path computes an out-of-range glyph offset.

[Cause]
version + font_size always spans 5 bytes, so a single compile-time
struct layout cannot represent both the 4+1 (legacy) and 3+2 (V3.2)
encodings. version[0] alone is not a valid discriminator because old
V3.0 fonts also carry major version 3 with the legacy 1-byte size.

[Solution]
Revert GUI_FONT_HEAD_BMP to a stable byte layout (version[4] + uint8
font_size). Add gui_font_bmp_is_v32() (version >= 3.2.0) and
gui_font_bmp_font_size() that reads uint16 @5-6 for V3.2+ and uint8 @6
otherwise. Route all header size reads and the typo-metrics version
gate through these helpers. Regenerate V3.2 demo fonts under
example/assets/font/v3.

[Validation] Verified on win32 simulator
- Hexdump confirms V3.2 fonts decode font_size 32, legacy fonts 24/28.
- New and legacy BMP fonts render correctly side by side.

[Need Cherry Pick to] default

Change-Id: Id2a9bada27397422f7b3b92e5a92b1372c9e3068

Author: luke_sun