Surprisingly large compile time

In a decently large project with 255 dependencies, this crate ranks 6th by compile time in a debug build:

| crate | build time |
| ------- | --------------|
| protobuf v2.18.1 | 5.2s |
| syn v1.0.58 | 5.2s |
| regex-syntax v0.6.18 | 4.0s |
| nix v0.18.0 | 3.5s |
| object v0.20.0 | 3.2s |
| clap v2.33.3 | 3.2s |
| procfs v0.9.1 | 3.0s |
| gimli v0.22.0 | 3.0s |
| serde_derive v1.0.116 | 2.8s |
| trust-dns-proto v0.20.1 | 2.6s |

It looks like approximately 40% of this crate's build time was introduced by the strategy employed in https://github.com/eminence/procfs/pull/48. As far as I can understand, the idea there was to nest macros so that the value produced `line!()` is relevant to the error. The problem is that this strategy causes this crate to balloon after macro expansion. If I run `cargo llvm-lines | head` in this crate, I get this:
```
Lines Copies Function name
----- ------ -------------
250761 (100%) 5134 (100%) (TOTAL)
10987 (4.4%) 1 (0.0%) procfs::process::status::Status::from_reader
7804 (3.1%) 1 (0.0%) procfs::process::mount::NFSEventCounter::from_str
5989 (2.4%) 1 (0.0%) procfs::process::stat::Stat::from_reader
3895 (1.6%) 1 (0.0%) procfs::diskstats::DiskStat::from_line
3875 (1.5%) 25 (0.5%) alloc::raw_vec::RawVec::grow_amortized
3698 (1.5%) 76 (1.5%) as core::ops::try_trait::Try>::branch
3018 (1.2%) 1 (0.0%) procfs::process::limit::Limits::from_reader
```
which is quite unusual, and points squarely at the large amount of code that (for example) `from_str!` expands into.

I'm also not convinced this strategy even produces useful errors, because its error messages are rendered useless by helper functions, such as `from_iter` and `split_into_num`.

Are you interested in a PR that doesn't introduce the panics back, but which tries to do something about the compile time regression from #48, even if it removes some of the file+line information?