Crate reorganization and upgrade to Rust 2018

[AaronKutch]

Some things to note:

• My problems with spacing where fixed by letting Rustfmt do its thing on the entire crate, and then following up with discarding specific line changes and adding #[rustfmt::skip] wherever I disagreed with Rustfmt.
• I will wait on updating the int.rs and uint.rs files to reflect the new functions and docs.
• All TODOs are either performance related or will be fixed in upcoming PRs.
• The three warnings will be fixed in upcoming PRs.
• There is something weird going on with the interaction between rand and cargo doc, but it is probably due to our outdated dependency should be fixed in a future commit. I plan on updating all the dependencies after the upcoming PRs but before 0.3.0 is released.
• R.I.P. commit history, but I promise not to do anything this invasive in the future.

Edit: uh-oh, Rustfmt did not fix the spacing between // and the rest of the comment. I will have to add on a commit to fix this

[AaronKutch]

I don't understand. I know this crate inside out by now, and I thought we were really close to merging this. Of course something as big as this is going to have problems, but I have looked over everything multiple times and you have double checked and revealed some small issues which I fixed. I can't think of any problems with what this PR in its current state would do to master, except for the needed rustfmt and pasting a bunch of stuff into uint.rs and int.rs (which is trivial stuff that I can do in two weekends, I have a rustfmt.toml ready to go with suggestions from the last time I tried to rustfmt everything). This PR plus the rustfmt and uint.rs stuff brings the crate back to a state that is strictly better than the current master in every way. I researched the TODOs and do not see any user-facing problems that did not exist beforehand. The minimum that is needed for a 0.3.0 from that point is adding on the new little and big endian constructors (I already found the function signatures I need, most of the changes from this will be in tests that use multi digit constructors), the brand new serialization functions (almost ready to go, I would not make my floating-point serialization function public of course, it needs a bunch of bike-shedding but could otherwise be used internally). After that, I cannot think of any breaking changes that users of the library could detect, except for the error refactor which will only be noticeable if someone is looking into the error struct.

This PR brings stuff like the overflowing functions which I have not made public yet out of an abundance of caution. My conservative estimate is that we could put out a 0.3.0 by the end of the year, and close every one of the issues open now by 2020. If you commit to closing this PR, my conservative estimate regarding the rate at which you accept PRs is that I will be graduated and have some kind of job that consumes all my time before this crate ever gets close to the 0.3.x I envision, and development will be softlocked worse than it already is.

[Robbepop]

Your work is not lost. The PR will not be reopened. My decision is final in this regard. However, I am happy to see this being split up into several many smaller PRs but that is upon yours decide.

I envision, and development will be softlocked worse than it already is.

I see it quite contrary to this. To be honest the big PRs that touch nearly every bit of a codebase pretty much drained all my motivation to work on other stuff for the crate because everything is going to change anyway and touching everything also conflicts with everything which is a mess. Maybe that is a personal or subjective opinion but that's how it felt to me always.

I will now work on some small things that are moving the crate into a better shape for contributions. Please reconsider splitting your PR up into smaller ones where each is focused on a single thing.