bug#8794: cons_to_long fixes; making 64-bit EMACS_INT the default

[Stefan Monnier <monnier@iro.umontreal.ca>]

> What else needs to be done before it's reasonable to install
> something like (b)?

Experience with it.  AFAIK a non-negligible fraction of users would be
happy to see such a feature because they need to access large files that
don't grow too fast (i.e. large but still within the 32bit limit) but:
- this category of files is fairly small: only files between 512MB and
  2GB, basically.  So a non-negligible fraction of those users may end
  up finding out that it only covers some percentage of their needs
  because the other files go beyond the 2GB limit.
- some other percentage of those users won't be satisfied either because
  such large files may prove too slow to access.
- so given the limited benefits, I want to make sure the drawbacks
  are negligible.  How is the memory use impacted by your change in
  "typical" sessions?  How is the CPU use impacted in typical sessions?
Benchmarks running the byte-compiler, Gnus, and any other intensive
Elisp code would be welcome.  Benchmarks testing the impact on
redisplay performance wold also be welcome.
I'd hope most of those benchmarks to show very little difference, but so
far I haven't seen any reports to make confident that this is the case.


        Stefan