Concerns from `binread` and `binwrite` design flaws

[jam1garner]

• [x] binread::io::Read doesn't imply std::io::Read, so binread::io::Read doesn't play nicely with escape-hatches (jam1garner/binread#23)
  • Should be fixed by b280c760
• [ ] helper types aren't shared between crates, so using both BinRead and BinWrite can cause issues when using FilePtr, Punctuated, NullString, etc.
  • This, obviously, should be resolved by the very existence of binrw
• [ ] attributes between BinRead and BinWrite can be redundant
  • Some progress on this design process can be found in #3
• [ ] binwrite is a long attribute name, supporting bw for write-specific traits should allow a more even experience between the two
  • This is intended to be fixed by introducing a combination of three top-level attributes (see #3 for more information):
    • br - read-only
    • bw - write-only
    • brw - read and writer
• [ ] BinWrite has no Args trait-associated type, so it isn't possible to provide additional context for writing
• [ ] BinWrite's attribute parsing is mediocre
• [ ] BinWrite doesn't have support for file magic (see #3)
• [ ] BinWrite doesn't have support for temp fields (is this actually useful?) (see #3)
• [ ] BinWrite doesn't have a second-pass like BinRead::after_parse, meaning things like filling in pointers afterwards is hard to do

[jam1garner]

After testing a few situations, b280c76 seems to do the trick for allowing you to lock yourself into using std::io, so that problem should be fixed.