Honour precision for %e/%E formatting (#13)

[CedricConday]

Closes #13 (the %.10e / %.10E checkbox; %.10f / %.10F was already done).

Problem

The e/E verbs ignored the precision argument entirely — they always emitted the natural (shortest) significand:

d := MustParse64("123456789")
d.Text('e', 3)                 // "1.23456789e+8"  (want "1.235e+8")
fmt.Sprintf("%.3e", d)         // "1.23456789e+8"

This was inconsistent with f/F, which already honour prec, and with the package's stated goal to "conform to standard Go formatting for float types" (DefaultFormatContext64 doc comment).

Fix

Round the significand to prec digits after the leading digit, using the context's rounding mode, then emit exactly that many fractional digits:

• Rounding reuses the existing Rounding.round + roundStatus primitives, so it respects the configured rounding mode.
• Zero-padding when prec exceeds the stored digits (%.12e of a 9-digit value).
• Exponent carry when rounding overflows the leading digit — 9.99 → 1.00e+1.
• A negative precision keeps the existing natural/shortest form.
• g/G is untouched: it selects the shortest scientific form, so it routes through the natural path unchanged.

The library keeps its own exponent style (no zero-padding, and a zero exponent is omitted for non-zero values); only the mantissa precision changed.

Tests

• The three existing Append(_, 'e', 0) assertions were asserting the old behaviour (precision ignored). They now use -1, the natural sentinel, so they still document the shortest form.
• New TestDecimal64ExpPrecision covers rounding, zero-padding, exponent carry (999999999 → 1e+9), half-to-even on exact decimals (9.95 → 1.0e+1), negatives and zero (0.000e+00), via Text, Append and the fmt.Formatter (%.*e) path.
• Full suite green (go test ./...), go vet and gofmt clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbUHs855FyBt2J7cG2Qmhh