ufmt: add support for hex printing and width specifiers

[hudson-ayers]

This change adds ufmt support for hex printing of numbers and for fixed-width printing up to widths of 18 using 0s or spaces
as padding. 0 padding is only supported for numbers. Custom fill characters and specified alignment is not supported. This change does decrease the size savings of ufmt relative to core::fmt, but brings them much closer to feature parity.

This change has not been submitted to the upstream ufmt repo, as it includes variations on several changes already submitted as PRs to that repo which have not been accepted: japaric/ufmt#25 and japaric/ufmt#26 .

A number of tests were added to verify that ufmt formatting is identical to core::fmt formatting for the supported additions. These can be run using cargo test --features=std from the ufmt directory.

In a closed-source codebase, switching apps to use ufmt instead of core::fmt reduced code size by a total of 7200 bytes across 4 apps, with the only loss in functionality being two locations that used fixed alignment printing.

In the same codebase switching to unmodified ufmt saved 12,500 bytes, at the expense of

• not being able to print any numbers in hexadecimal
• not being able to print fixed width fields

Notably, this support is somewhat pay-for-what-you-use: The savings were ~10kB before I switched back to hex/fixed width formatting where it had been used before. Accordingly, for users of ufmt who do not need/want any of this functionality, the overhead is about a 20% increase in code size. I suspect I can get that number somewhat lower, but wanted to submit this as-is for feedback before I spend too much time optimizing.

[alistair23]

I think this is a great idea. The size cost is worth the ability to print in hex.

Can we keep the #[deny(warnings)]` in? Also this seems to be failing CI

[hudson-ayers]

CI is fixed

[jrvanwhy]

bors r+

[bors]

Build succeeded:

• ci
• size-diff