[WIP] Add parsing of lexical numbers

[Zij-IT]

I figured I would submit a WIP pull request to get your opinion on it, before I spend time writing documentation (as well all know that takes forever), and make any changes that you feel are necessary.

This pull request adds the following public elements:

• Number - Parses a number given a specific format provided by the lexical crate.
• number - Which is just the constructor function.
• format - A reexport of lexical::format

This pull request changes the the following:

• Relaxes the bound on InputRef::skip_bytes to allow for number to work with SliceInput. I am admittedly not sure if this is the right call, but it seemed like the previous bound was unnecessarily strict.

Questions:

• Does this look like the API that you would be expecting for a parser like this?
• Are there any surprises that I should be aware of that force Number to require I: StrInput?
• Is there any reason for skip_bytes to require StrInput that I should be aware of?
• Should the aforementioned bound be set-back to StrInput?.

[Zij-IT]

Ah forgot to tag the issue. #398

[zesterer]

I think cfg(any(feature = "regex", feature = "lexical-numbers")) is the proper thing to do here.

[zesterer]

It's a bit of a shame that we end up needing to specify the type parameters like number::<RUST_LITERAL, _, _, _>() each time due to the const generic, but by the looks of things there might not be a way around this.

[Zij-IT]

I agree, but I have no clue how we could even try to work around this, because parse_partial uses the RUST_LITERAL generically.

Unrelated, but It may also be worth it to use const_assert to make sure that the literal provided is valid.

[zesterer]

This seems reasonable. That said, it might be worth putting behind an unstable feature flag too for now (with lexical-numbers = ["lexical", "unstable"]). There's enough weirdness with the design (not your fault, just a product of lexical's API) that it would be nice to change this in breaking ways post-release.

[Zij-IT]

@zesterer Should be merge-ready :)

[zesterer]

Thanks!