GCC 10 uses -fno-common by default, which makes multiple definitions of the same symbol in multiple
object files an error. This was used in the userspace test library, and broke with GCC10. Therefore,
the relevant symbol is now marked as "weak" to solve the issue and to clarify the intent.

Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>

The test userprog/exec-missing verifies that exec() returns -1 when
starting a process for which the binary is not found. Since the failure
of load() is discovered after a new process has been created, the output
'no-such-file: exit(-1)' will be visible in the output. The problem is
that we do not know when this happens with respect to the thread calling
exec(). Due to how the tests are designed, the time when 'no-such-file'
terminates is important. Some of the cases were listed as acceptable
outputs, but I found some acceptable outputs missing from there, namely
if 'no-such-file' for some reason takes quite some time terminating, or
even terminates after the 'exec-missing' process exits. As there is no
synchronization between these processes (nor can it be), we do not know
which one terminates first.

Effectively, I added the following possible outputs to the test, as I
find them reasonable outcomes of a correct implementation (in very
unfortunate circumstances, or when printing a lot in process_cleanup):

(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
no-such-file: exit(-1)
exec-missing: exit(0)

(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
exec-missing: exit(0)
no-such-file: exit(-1)

Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>