This code is adapted from pixelherodev paste from IRC
I have added a new fmt option to handle printing slice values ``{v}`` or ``{V}``
While i think it can be made the default, i want your opinion about it
```zig
var slicea = [0]u32{};
var sliceb = [3]u32{ 1, 2, 3 };
std.log.info("Content: {v}", .{slicea});
std.log.info("Content: {v}", .{sliceb});
```
will print:
```
info: Content: []
info: Content: [1, 2, 3]
```
Question:
Should we drop ``{v}`` and make it the default behavior?
Turn the FSM parser into a linear one so that's easier to implement new
features and/or more error checking without adding more and more states.
Functionally-speaking the two parsers are at feature parity.
This implementation tries to do the right thing (TM) by treating the
sign as part of the number itself, therefore the alignment parameter
applies to both the sign and the digits.
In other words the format string `{:>4}` with -1 as input will not
output `- 1` but ` -1`.
And let's default to right alignment for everything as that's what users
want, especially when printing numbers. Many implementations use
different defaults for numeric vs non-numeric types, let's strive for a
consistent behaviour here.
This reverts commit 11d38a7e520f485206b7b010f64127d864194e4c.
The benefits of this commit are not enough to justify the compromise
that it made.
closes#5977
When there are no format parameters, it simply calls `writeAll`. This
has the effect of no longer emitting a compile error for using `{}` and
not having any parameters, however, at this point in the development
process of Zig I think that tradeoff is worthwhile.
On the other hand, it might be OK to simply define formatting to work
this way. It's a common pattern to use the formatting function's format
string `"like this", .{}` instead of `"{}", .{"like this"}`, which can
lead to accidentally putting control characters in the formatting
string, however, with this change that works just fine.
