Properly support padding in parsers

[pitdicker]

trafficstars

With our strftime syntax it is possible to specify padding (zero padding %0?, spaces as padding %_?, no padding at all %-?, or the default). This maps to three variants in the Pad enum : None, Zero and Space. That is good enough for formatting.

For parsing we currently just ignore whatever is specified as padding. We trim all whitespace, accept leading zero(s), and read a number.

There are cases where users want parsing to be forgiving (as it has always been in chrono), and others where users want the parser to be very strict.

I propose that in 0.5 we add at least one more variant to the Pad enum. That should allow the parser code to know if the users wants a forgiving parser (by not specifying anything about padding), or if he explicitly asks for none, zero or space padding.

Related issues: #1112, #1118. The PR that was merged in the 0.5 branch to be exact about whitespace exaggerates this issue, because with it the parser code now only accepts no padding or zero padding (#807).

[pitdicker]

If we would add a Default variant to Pad that would mean we have to learn the formatting and parsing code what the defaults for all possible formatting fields are. That is not very elegant.

Instead we should add something like ZeroOrNone:

pub enum Pad {
    None,
    Zero,
    Space,
    ZeroOrNone,
}

Zero and Space would require padding, None would disallow padding, ZeroOrNone would allow optional zero padding.

Alternatively we can define Zero to allow optional padding and add a ZeroRequired variant. That would be closer to the current behaviour. The only part that would make that a potentially breaking change on 0.4.x is the addition of an extra enum variant.

[djc]

I feel like your Pad::ZeroOrNone should maybe be expressed as Option<Pad> instead? What does "the default" end up meaning in the formatting use case?