Do not fix '417075 - pwritev(vector[...]) suppression ignored' but produce a warning.

Do not fix '417075 - pwritev(vector[...]) suppression ignored' but produce a warning.

  - The release 3.15 introduced a backward incompatible change for
    some suppression entries related to preadv and pwritev syscalls.
    When reading a suppression entry using the unsupported 3.14 format,
    valgrind will now produce a warning to say the suppression entry will not
    work, and suggest the needed change.
For example, in 3.14, the extra line was:
  pwritev(vector[...])
while in 3.15, it became e.g.
  pwritev(vector[2])

3 possible fixes were discussed:
 * revert the 3.15 change to go back to 3.14 format.
   This is ugly because valgrind 3.16 would be incompatible
   with the supp entries for 3.15.
 * make the suppression matching logic consider that ... is a wildcard
   equivalent to a *.
   This is ugly because the suppression matching logic/functionality
   is already very complex, and ... would mean 2 different things
   in a suppression entry: wildcard in the extra line, and whatever
   nr of stackframes in the backtrace portion of the supp entry.
 * keep the 3.15 format, and accept the incompatibility with 3.14 and before.
   This is ugly as valgrind 3.16 and above are still incompatible with 3.14
   and before.

The third option was deemed the less ugly, in particular because it was possible
to detect the incompatible unsupported supp entry and produce a warning.

So, now, valgrind reports a warning when such an entry is detected, giving
e.g. a behaviour such as:

==21717== WARNING: pwritev(vector[...]) is an obsolete suppression line not supported in valgrind 3.15 or later.
==21717== You should replace [...] by a specific index such as [0] or [1] or [2] or similar
==21717==
....
==21717== Syscall param pwritev(vector[1]) points to unaddressable byte(s)
==21717==    at 0x495B65A: pwritev (pwritev64.c:30)
==21717==    by 0x1096C5: main (sys-preadv_pwritev.c:69)
==21717==  Address 0xffffffffffffffff is not stack'd, malloc'd or (recently) free'd
So, we can hope that users having incompatible entries will easily understand
the problem of the supp entry not matching anymore.

In future releases of valgrind, we must take care to:
  * never change the extra string produced for an error, unless *really* necessary
  * minimise as much as possible 'variable' information generated dynamically
    in error extra string.  Such extra information can be reported in the rest
    of the error message (like the address above for example).
    The user can use e.g. GDB + vgdb to examine in details the offending
    data or parameter values or uninitialised bytes or ...

A comment is added in pub_tool_errormgr.h to remind tool developers of the above.