[common_test] Extend valid interval for approximate timer values in tests

When matching the result of tests of timetrap timeouts, the actual
time is measured against the expected time, and an interval of +/- 2%
was seen as correct result. This turned out to fail on some platforms
and is now changed to 5%.
[common_test] Extend timeout values for slave nodes in ct_master_SUITE

Some tests in ct_master_SUITE failed on some platforms with
boot_timeout when trying to start slave nodes. The default timeout
value was 3 seconds, and it is now extended to 10 seconds in these
tests.

To avoid similar errors with init_timeout and startup_timeout, these
are both exteded from 1 second default value to 10 seconds in this
test.
[common_test] Changed call to publick_key to use documented interface

Earlier used 'OTP-PUB-KEY':encode/2 - now public_key:der_encode/2 instead.
[common_test] Avoid hanging ct@host node if crypto does not exist

ct_netconfc:init_per_suite called ct_test_support:init_per_suite
before checking if crypto exists. This caused the slave node (ct@host)
to be started even though the suite would be skipped when crypto did
not exist - which in turn caused a hanging ct node since end_per_suite
is not run in a skipped suite. This has been corrected.
[common_test] Extend timetrap time in ct_hooks_SUITE

This suite often fails with timetrap timeout on some test machines.
Replace use of driver_send_term() with erl_drv_send_term()
Replace use of deprecated functions in test cases

driver_send_term() replaced by erl_drv_send_term().
driver_output_term() replaced by erl_drv_output_term().
Fix documentation
Add 'port_count' and 'port_limit' to system_info/1 spec
Add workaround for CentOS/RedHat writev bug to inet_drv
Clean up and make the fix work on windows.

Thanks to Tony Rogvall.
Report spec discrepancy on mismatching lists

This patch enables Dialyzer to detect cases where a function has a specification
for a return type containing some list with elements different than the ones
Dialyzer's own algorithm can infer e.g. a function specified to return [atom()]
when actually [[atom()]] is returned.

Previously Dialyzer remained silent, under normal operation, seeing that these
two types have the empty list as a common element, so they were not 'completely
irrelevant'.
Change proposed scheduler wakeup strategy to be the default
Add +stbt erl command line switch
make/fakefop: adapt to make/otp.mk.in changes
make/fakefop: update copyright years
make/fakefop: do not report what file is written
make/fakefop: slightly change placeholder text
make/fakefop: repair pdf structure and make content static
Use share flags for all file operations on Windows

Some file operations provided by the Erlang file module
didn't open the target file with all the file share flags.
This made some concurrent file operations against the
same file fail on Windows, while on other platforms such
as GNU/Linux or Mac OS X they succeed. The operations will
fail only if they're performed concurrently by different
threads (async IO threads or scheduler threads).

For example, one Erlang process does a file:delete/1 call
while another Erlang process is doing a filelib:file_size/1
call. This made the former process get an eacces error from
the file:delete/1 call. On GNU/Linux or Mac OS X the call would
succeed. Another example is if one Erlang process attempts to
open a file for reading while another one is in the middle of
a file:read_file_info/1 call (after it opened the file and
before it closed the file).

It's easy to verify that if a file is not open with all the
share flags, it's impossible for other threads (even if they
belong to the same OS process) to open the file while the
file is not closed by the first thread.
The following test program shows this:

 #include <windows.h>
 #include <iostream>

// Must be an existing file
//#define SHARE_FLAGS (FILE_SHARE_READ)

static DWORD WINAPI MyThreadFunction(LPVOID lpParam);
static char *lastError();

int main(int argc, char *argv[])
{
    DWORD   threadId;
    HANDLE  threadHandle, hFile;

    hFile = CreateFile(FILENAME, GENERIC_READ, SHARE_FLAGS, NULL,
                       OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) {
        std::cerr << "File open error from main: " <<
		lastError() << std::endl;
        return 1;
    }
    std::cout << "Main thread opened file successfully" << std::endl;

    threadHandle = CreateThread(NULL, 0, MyThreadFunction, NULL, 0, &threadId);
    if (threadHandle == INVALID_HANDLE_VALUE) {
        std::cerr << "Thread create error from main: " <<
		lastError() << std::endl;
        return 1;
    }
    WaitForSingleObject(threadHandle, INFINITE);
    CloseHandle(threadHandle);
    CloseHandle(hFile);
    return 0;
}

static DWORD WINAPI MyThreadFunction( LPVOID lpParam )
{
    HANDLE hFile;

    hFile = CreateFile(FILENAME, GENERIC_READ, SHARE_FLAGS, NULL,
                       OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) {
        std::cerr << "File open error from second thread: " <<
		lastError() << std::endl;
        return 1;
    }
    std::cout << "Second thread opened file successfully" << std::endl;
    CloseHandle(hFile);
    return 0;
}

static char *lastError()
{
    static char *buf = NULL;
    DWORD dw = GetLastError();

    if (buf != NULL) {
        LocalFree((LPTSTR) &buf);
    }
    FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM |
                  FORMAT_MESSAGE_IGNORE_INSERTS,
                  NULL, dw, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                  (LPTSTR) &buf, 0, NULL);
    return buf;
}

Rnning this program with SHARE_FLAGS set to 0 (as efile_fileinfo()
does for e.g.), shows that the second thread is unable to open the
file:

    C:\cygwin\home\fdmanana\tmp>touch foo.bar
    C:\cygwin\home\fdmanana\tmp>threads_fopen_test.exe
    Main thread opened file successfully
    File open error from second thread: The process cannot access the
    file because it is being used by another process.

Changing the program's SHARE_FLAGS to FILE_SHARE_READ, shows that
both threads are able to open the file:

    C:\cygwin\home\fdmanana\tmp>touch foo.bar
    C:\cygwin\home\fdmanana\tmp>threads_test.exe
    Main thread opened file successfully
    Second thread opened file successfully

Same logic applies to opening files for writing or deleting and
renaming files while they're open by some other thread that didn't
specify the flags FILE_SHARE_WRITE and FILE_SHARE_DELETE.