Fix -Wstringop-truncation warnings in optimized asan build

[kazarmy]

This pr fixes the following warnings in the optimized asan build of rizinorg/rizin#260 (https://github.com/rizinorg/rizin/runs/2031121204, View raw logs, search for "-Wstringop-truncation" and see first 2 hits):

2021-03-04T12:50:27.0361388Z In file included from /usr/include/string.h:495,
2021-03-04T12:50:27.0362944Z                  from ../subprojects/capstone-bundled/cs.c:16:
2021-03-04T12:50:27.0364887Z In function ‘strncpy’,
2021-03-04T12:50:27.0366271Z     inlined from ‘fill_insn’ at ../subprojects/capstone-bundled/cs.c:579:11:
2021-03-04T12:50:27.0368213Z /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 31 bytes from a string of length 31 [-Wstringop-truncation]
2021-03-04T12:50:27.0369934Z   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
2021-03-04T12:50:27.0370668Z       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2021-03-04T12:51:08.4437002Z In file included from /usr/include/string.h:495,
2021-03-04T12:51:08.4438758Z                  from ../subprojects/capstone-bundled/arch/Sparc/SparcInstPrinter.c:29:
2021-03-04T12:51:08.4440765Z In function ‘strncpy’,
2021-03-04T12:51:08.4442293Z     inlined from ‘Sparc_printInst’ at ../subprojects/capstone-bundled/arch/Sparc/SparcInstPrinter.c:361:3:
2021-03-04T12:51:08.4444167Z /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound 64 equals destination size [-Wstringop-truncation]
2021-03-04T12:51:08.4448603Z   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
2021-03-04T12:51:08.4449426Z       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[ret2libc]

Please submit these fixes upstream, then cherry-pick here. I bet they will want the fix as well and we would all benefit if the fixes are first there instead of keeping our own fork (which unfortunately we already have, but the plan is to use clean upstream at some point).

[kazarmy]

Ok capstone-engine#1730