Remap inode numbers to fit into 32bit integer space on build (RhBug:714678)

Remap inode numbers to fit into 32bit integer space on build (RhBug:714678)

- 64bit inode numbers lose their uniquity when brutally truncated
  to 32bit integers as we've done so far. This can and will cause rpm
  (and cpio) to mix up arbitrary file entries as hardlinks and vice versa.
- As the only interesting aspect of inode numbers is whether they're
  equal to something else or not, we dont have to carry the "physical"
  on-disk value to preserve semantics. So we can just remap the
  inode numbers to something that fits our 32bit integer tags
  without causing compatibility complexies with older rpms and
  cpio (and since we can't handle more than INT32_MAX files in a package
  anyway, breaking compatibility for this would be just braindead dumb).
  An extremely simple way to achieve this is to use our
  build-time file list index as the basis of stored inode number.
- In theory this breaks inode-device pairing, but as the buildroot
  cannot span across filesystems in any remotely normal conditions,
  just add a sanity check to catch the dirty tricksters...
- Based on a patch by Zdenek Pavlas, just further simplified and
  buildroot fs boundary sanity check added.