bfd_vma -> new file?

[Doug Evans]

Does anyone have any objections to pulling bfd_vma and company
out of bfd.h and into a separate file?

bfd_vma is such a widely used quantity it'd be useful to have
it available without having to drag in the rest of bfd.h.

I don't have a tested patch so I may be missing something that
makes the "cure" worse than the "disease".
However, methinks this is purely a mechanical operation.

Alternatively one could have a quantity that doesn't have bfd
in its name and then base bfd_vma on it.
That might even be better, but that's a lot more work for
seemingly marginal gain.  And I'm not sure it makes sense to
have two types that do the same thing.

Although ...
Given a desire to chuck bfd, maybe a useful first step is to
chuck bfd_vma (not all in one day of course).
No claim is made that bfd will ever go away, but if something
starts to take its place for elf, and more and more things use
it instead of bfd, we might still want to have a bfd_vma kind-of type
that is shared by both (and I can imagine how much the new libelf
(or some such) folks would want to use anything with bfd in the name :-)).

Alternatively, one could have an independent type and duplicate
the bfd_vma type selection machinery (how big it is), but how big
it needs to be is intimately tied to what's effectively in --enable-targets.

Alternatively, all that's really needed is BFD_ARCH_SIZE.
The rest of bfd_vma (and company) is derived solely from it
and BFD_HOST_{,U_}64_BIT.
One could move that to a separate header.

The main reason for the request is that I use it in
cgen but I loathe dragging in the rest of bfd.h when I
don't have to.  When I was at Cygnus I remember other situations
where I wanted bfd_vma without bfd.h though I can't remember
now what they were.

Opinions?