Show binary exports, entrypoint, and imports

[wagoodman]

Partially implements #661

This PR adds the following indications to the file.Executable object:

• hasEntrypoint denotes if the binary is self-executable
• hasExports denotes that the binary can be used as a library
• importsLibraries denotes which dynamic libraries a binary needs

Why not just indicate isLibrary? Mainly because some executable formats can support a binary being both a library and a self-executing application simultaneously:

$ readelf -h /bin/busybox | grep "Entry point address"
  Entry point address:               0xd8f4

$ nm -D --defined-only /bin/busybox | grep ' T \| W \| B '
00000000000b8974 T _fini
000000000000c010 T _init
00000000000b7618 T endutxent
00000000000b7624 T getutxent
00000000000b7668 T pututxline
00000000000b76bc T setutxent
00000000000b76e8 T updwtmpx

(anything that isn't U is an export)

Why not make relationships between binary files instead of declaring the imports as attributes on the file object? There is some discussion about this, but this PR only goes so far; no new relationships are being added in this PR, but it is important to be able to know:

• about imports where there is no binary file or package that suffices, thus we would not show the dependency without it required to be installed
• exactly which imports are declared on a binary. At a package level this kind of information could be lost some (say if a package provides multiple binaries and we don't know which one).

This functionality has been implemented for ELF, Mach-o, and PE binary formats.

[kzantow]

LGTM 👍

[kzantow]

Isn't this what the UnionReader is for?

[wagoodman]

no a union reader only makes the reader easier to use for seeking and such:

type UnionReader interface {
	io.Reader
	io.ReaderAt
	io.Seeker
	io.Closer
}

Where as we could be individually unwrapping the multiple binaries from "universal" or multi-architecture binaries: https://github.com/anchore/go-macholibre/blob/5df1434a0b50a4fe3e1dae035d10d4c977369e43/universal_binary.go#L143 .

I've descoped this from this particular PR.