gscreen -tell gscreen to look for skins in skin folder

Gscreen looks for 'built-in' skins in the skin folder.
This is more convienient for users as they don't need to copy the
skin files - they just do INI changes.
If they want to make custom changes then they can copy the files into
their config and modify them there.

So Gscreen checks the config file for skin files first,
then the skin folder next
then finally it uses the stock default screen.
I probably should make the default screen a skin too...
gscreen config -add skin folder and files, remove skin files from sample configs

We now have 'built-in' skins so we don't want them in sample configs folder.
I have tempararily left Gmoccapy in the sample configs so as to let Norbert prepare for the change.
gscreen config -rename gscreen_custom to 9_axis

more desciptive and the skin files had to be renamed anyways
debian -add gscreen folders and files to be installed

This should add the skin folder and files when linuxcnc is installed.
Also noticed gscreen/images was missing the /* to actually add image files..
gladevcp -have the calculator show only integers when switch is on

When using the calculator as a numerical entry sometimes we onnly want
integers - such as when using it for run-from-line entry.
We already had an integer_entry_only method to hide the decimal
button, now it also makes the display only show integers.
classicladder: cast to double to do FP arithmetic on integers
mb2hal: compute timeouts with integer math

The prior code uses questionable casts to do what can be done with
modulo integer math.

The new code does not give *exactly* the same timeout, because the
calculation
    (int)(float)(this_mb_tx->mb_response_timeout_ms / 1000.0)
is subject to rounding errors, while
    timeout.tv_sec  = this_mb_tx->mb_response_timeout_ms / 1000;
is not.  For example for a response timeout of 2001ms, the old code
would actually give a timeout of 2.000999 seconds, while the new code
gives the correct result of 2.001000 seconds.  The new code begins
giving "radically" different (but again more correct) values around
65536 seconds due to the loss of precision in float arithmetic
(65536.000f == 65536.001f when you have a 24-bit mantissa)

Tested by cut&paste of old and new code into a test harness:

struct timeval fold(long arg)
{
    struct timeval timeout;
    timeout.tv_sec  = (int)(float)(arg / 1000.0);  //int part of the float
    timeout.tv_usec = ((float)(arg / 1000.0) - timeout.tv_sec) * 1000000;
    return timeout;
}

struct timeval fnew(long arg)
{
    struct timeval timeout;
    timeout.tv_sec  = arg / 1000;
    timeout.tv_usec = (arg % 1000) * 1000;
    return timeout;
}

void check(long timeout) {
    struct timeval ta = fold(timeout);
    struct timeval tb = fnew(timeout);

    double a = ta.tv_sec + ta.tv_usec * 1e-6;
    double b = tb.tv_sec + tb.tv_usec * 1e-6;
    if(fabs(a - b) > .001) {
    // if(ta.tv_sec != tb.tv_sec || ta.tv_usec != tb.tv_usec) {
        printf("fail tv_sec %lu: %lu.%06lu != %lu.%06lu\n", timeout,
            (long) ta.tv_sec, (long) ta.tv_usec,
            (long) tb.tv_sec, (long) tb.tv_usec);
    }
}

int main() {
    long i;
    for(i=0; i<1000*1000*1000; i += 500) {
        check(i);
        check(i+1);
        check(i+499);
    }
}
vfs11_vfd: don't needlessly cast

In the expression 'max_freq/100.0', max_freq is converted to (double-
precision) floating-point before being divided by 100.0, so the cast
(to single-precision float) is not needed and possibly harmful for
max_freq > 2^24 (an unlikely value)