fix(resources-management): stop aborting the rendering on a valid quantity

[Suselz]

What is broken

#217, released as 1.72.23, gave helm_lib_resources_management_cpu_units_to_millicores a fail
branch it never had and narrowed both helpers to two regexes. The Kubernetes quantity grammar is
wider than those regexes, so a valid quantity now aborts the rendering of the whole chart:

cpu "+1"     FAIL   was 1000          <- rendered correctly before
cpu "-1"     FAIL   was -1000
cpu "1."     FAIL   was 0
cpu "100u"   FAIL   was 0
cpu "100n"   FAIL   was 0
cpu "1k"     FAIL   was 0
mem "+1Gi"   FAIL   was 1073741824
mem "abcGi"  FAIL   was 0

A CRD that validates a quantity with the standard pattern accepts every one of them — a leading
sign, a trailing dot, and the n, u, k, M, G suffixes are all part of it — and there is no
Quantity canonicalization on the way to the template, so the value arrives verbatim.

+1 is the sharp case. It produced the right number before and takes the release down now, which
is the same class of failure #217 set out to remove, reached through a different input and from a
shared helper rather than one module.

Found in review of deckhouse/deckhouse#23170 by @AlwxSin, who measured the CPU cases. The two
memory cases are the same defect in the other helper.

What this pull request changes

Both helpers now parse the grammar they are given: an optional sign, a decimal mantissa with either
side of the point optional, a decimal exponent, and the n, u, m, k, M, G, T, P, E
and Ki...Ei suffixes. Exact integer arithmetic still covers an integer mantissa, so no value
changes the result it has today.

Nothing that used to produce a number aborts any more:

cpu "+1"     -> 1000        cpu "0.5"    -> 500
cpu "-1"     -> -1000       cpu "500m"   -> 500
cpu "1."     -> 1000        cpu "2"      -> 2000
cpu "100u"   -> 1           cpu "abc"    -> 0
cpu "100n"   -> 1           mem "+1Gi"   -> 1073741824
cpu "1k"     -> 1000000     mem "abcGi"  -> 0

An unparsable CPU value yields 0 as it did before 1.72.23. A memory value carrying a known
suffix and an unparsable mantissa does the same. The fail of the memory helper is reached only by
a value that carries neither a known suffix nor a number.

The helpers convert, they do not validate. A negative quantity comes back as a negative number, as
it always did, and a result that does not fit an int64 comes back as 0. Rejecting either belongs
to the caller — the doc comments say so.

The memory helper also gained the n, u and m branches it was missing, so 100m, 100n and
100u convert instead of aborting, and both helpers check the int64 range before converting, so
1E, 1Ei and 10P on the CPU path come back as 0 rather than saturated or wrapped.

Verification

helm unittest ./tests — 420 tests pass. The two helper suites gained a case per quantity form,
including the sign, the trailing dot, the exponent and every suffix.

helm_lib_resources_management_original_pod_resources gained the assertion that was missing when
the zero was introduced, and which would have caught it:

- equal: {path: result_fractional_limits_cpu, value: "750m"}   # 0.5 cores * 1.5
- equal: {path: result_fractional_requests_cpu, value: "0.5"}

Until now that suite only asserted the rendered block was non-empty, which a limits.cpu: 0m
against requests.cpu: 0.5 satisfies.

Release

The chart version is bumped to 1.72.24. The platform picks it up through
make update-lib-helm version=1.72.24. deckhouse/deckhouse#23170 carries the 1.72.23 bump today
and has to move to 1.72.24 before it merges, so that a patch release does not ship the abort.