The go runtime generates profiles in profile.proto format
without symbols or mappings. The expectation is that these
can be symbolized by passing the binary name to pprof.

The mechanism pprof uses relies to override the binary relies
on there being a mapping, and previously we moved the creation
of fake mappings to the legacy profile handlers, so profiles
parsed from profile.proto with no mappings can no longer be
symbolized.

Special case this situation to create a fake mapping and associate
all locations to it if there is a command line override but no
mappings.

When the source is remote and a mapping doesn't have either build ID or
file field set, the file field is set to the source URL so that the
proper source from the source mapping is used during symbolz processing.
Before this change, the file field would continue to point to the URL
producing the URL in pprof output which confuses users.

With the change it resets the file field back to the empty string. It
also now skips the URL-like paths during local symbolization as
reading at that path is not going to succeed.

We discussed switching to generating more unique IDs. On the second
thought, I propose leaving these to be URLs as that seems unique enough
and in case this field leaks into the tool or log output seeing the URL
seems still friendlier than some arbitrarily prefixed string.

Also update the build instructions to use go get