Internal testing ran into an issue where occasionally MessageT() would panic with an unknown return code back from ydb_message_t() in the go/ydbgo34 test - specifically the part that ran the ydbgo34a module. This always happened when ydbgo34a selected the random signal SIGHUP. In this test, SIGHUP is the only signal that we currently allow to actually drive the YottaDB signal handlers for various reasons described in that test. Driving the YottaDB signal handler caused the exit handler to be driven earlier than it otherwise would for other signals. This caused any still-active goroutine to get a CALLINAFTERXIT error that looks like the following:
```
%YDB-E-CALLINAFTERXIT, After a ydb_exit(), a process cannot create a valid YottaDB context
```

This error would be returned to TpST() who called NewError() and then MessageT() to get the error text. Unfortunately, there was an issue in a recently added commit (f2f8946c) which is part of #34 (closed) that removed the sign from the error number passed into MessageT() before it tests for YDB_ERR_CALLINAFTERXIT which is negative. Because this error was not recognized in the hard-coded checks, and because we called MessageT() after the YottaDB engine had been shutdown, MessageT() would panic with a message like the following:
```
panic: YDB: Error calling ydb_message_t() for argument 150381530: -150381530
```

This change fixes this issue by using an unchanged copy of the argument in the hardcoded comparisons and when the value is a parameter to another routine. The positive version of the parameter is only used for extracting the facility value out of the error number.

This change also cleans things up slightly changing serial if checks into a switch{}.