Allow ssp_test:read to pass more reliably

It appears that the stackframe layout can be slightly different depending on
compiler and target architecture. For example, when using CHERI LLVM for RISC-V
we can actually overflow the buffer by up to 8 bytes without SSP detecting it.
Fix this by increasing the overflow to 15 bytes.

Reviewed By: ngie, emaste
Differential Revision: https://reviews.freebsd.org/D28997

Fix up previous commit

- Apply the logic to the FreeBSD block
- Fix a typo with the getconf(1) call that I would have caught, were
it not for the fact that I got the blocks wrong.
- Consolidate the hardcoded buffer sizes to the NetBSD block.

This would have been discovered had I run the test on a system where
PATH_MAX != 1024 (I don't have that at my disposal right at this moment).

MFC after: 3 weeks
MFC with: r318210
Sponsored by: Dell EMC Isilon

ssp_test:read:: query the value of MAXPATHLEN via getconf(1)

In the event the value of PATH_MAX was changed, the assumption that
MAXPATHLEN is 1024 (and hence the buffer length required to trigger
SSP to fail for read(2)) would be invalidated. Query getconf(1) for
the actual value of MAXPATHLEN via _XOPEN_PATH_MAX instead, and
increment the value by 1 to ensure that the SSP support tests the
stack smashing support properly.

MFC after: 3 weeks
Sponsored by: Dell EMC Isilon

Don't dump core files with lib/libc/ssp/ssp_test and lib/libc/gen/assert_test

The default `sysctl kern.corefile` value is compatible with `kyua test` (FreeBSD
will dump to the current directory). If it's set to an absolute path however,
`kyua test` will not be able to clean up the corefiles after the fact

The corefiles have little value when testing the behavior of feature behavior,
so just disable corefile generation

MFC after: 1 week
Obtained from: Isilon OneFS (^/onefs/head@r511419)
Sponsored by: EMC / Isilon Storage Division

Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 Jenkins
job

The h_raw application doesn't do proper bounds checking without the option
being supplied via the build, which means that it doesn't throw signals and
fail as expected

PR: 196430
X-MFC with: r276479

Port lib/libc/ssp to FreeBSD

In most cases, the buffers and data were resized, but when dealing with the
helpers, some of the code was adjusted to fail more reliably

Submitted by: pho