libfdisk: gpt: accept numeric attribute bits 0-2

libfdisk: gpt: accept numeric attribute bits 0-2

gpt_entry_attrs_from_string() applied the GUID-specific range check
(48-63) to every numeric input. As a result, bare numeric bits 0, 1
and 2 were silently rejected. Those bits are RequiredPartition,
NoBlockIOProtocol and LegacyBIOSBootable, so the only way to set
them was by name.

That trips up any tool that emits attributes as a numeric list.
systemd-repart, for instance, formats Flags= as a comma-separated
list of decimal bit numbers, so Flags=0x4 (LegacyBIOSBootable) was
silently lost.

Split the numeric validation by source token:

  - bare <bit> accepts {0,1,2} or [48,63];
  - GUID:<bit> stays at [48,63]; the GUID: prefix belongs to the
    GUID-specific range only;
  - bits 3-47 are still rejected (UEFI-reserved).

Two drive-by fixes in the same block:

  - 'end == str' compared strtol's end pointer to the function's
    input rather than the current parse position; replace with
    'end == p'.
  - The diagnostic for an unsupported numeric bit printed p after
    the GUID: strip, so "GUID:5" came out as "5". Save the token
    start and pass that to fdisk_warnx().

Tests cover the new accepted forms (bare 0-2, mixed "<n>,GUID:<m>",
hex) and the still-rejected reserved range.

Fixes: https://github.com/util-linux/util-linux/issues/3353
Reference: https://github.com/systemd/systemd/issues/35591
Signed-off-by: Jamie Magee <jamie.magee@gmail.com>