Having sysctl kernel.yama.ptrace_scope=1, one may only call ptrace
attach on direct descendants. The same restriction is also checked for
`process_vm_readv`/`writev` and certain procfs files. However, if an
intermediate parent process already exited, we could end up with a
grandchild that we're still ptracing but isn't our descendant, so we
can't use the `process_vm` functions anymore -> `EPERM`.

We already had a fallback here for `EFAULT`, to just use `ptrace` memory
access, so use the same fallback after `EPERM` too.

If a process initially failed to attach threads, a `pthrd_printf` was
indicating that it would try again, but the process was getting erased
from the set while incorrectly causing the iterator to double-increment.

Now the messages about "will try again" and "now an error" are changed
to simply report an immediate error, and it continus the loop after
process erasure to avoid incrementing the iterator again.

1. An indirect jump may be shared by several different jump tables. Add value set representations so that we can union jump targets from different tables.
2. Separate input absloc from absloc at the current address, as they may have different values

In the attach loop over waitfor_startup(), processes which fail are
erased from the set. However, the iterator was getting incremented
again, which will skip the next process or even cause undefined behavior
if already at the end of the list.

With GCC 6.2.1, that UB manifested as an infinite loop on a self-
referential rbtree node.

The simple solution is to `continue` the loop after `erase(i++)`, as is
done in many other places with this same pattern.

If `int_thread::createThread` failed to actually attach to the thread,
it was leaving the thread object in the process in the `neonatal` state.
This failed assertions later when trying to stop all of the process's
threads, as it would have handler `stopped` and generator `neonatal`.

Now when a thread attach fails, it is set to `errorstate` and removed
from the active thread pools. The assumption is that this thread simply
exited before we could attach, but we can't be sure of that without
having access to the ptrace return code (`ESRCH`).

An address passed to `mmap` is just taken as a hint, and the OS may
return something wildly different if that address is not available.
This is undesirable when we're trying to create a constrained alloc.

Now we will check that the address is in the requested range before
accepting it. Otherwise, unmap it and try a new hint.

When we encounter instructions without instruction semantics, we should stop jump table analyis.
In such case, if the missing instruction is key to the jump table analysis, we will not be able to
resolve it. If the missing instruction is not relevant to the jump table analysis, the slicing
is including unnecessary instruction. In either case, we should fix things.

When additional threads are found during the attach process, we should
synchronize to their stopping point, and check for new threads again,
until no new threads are found. This keeps a more consistent state if
threads are racing to start while we're attaching.