Suricata

With modern C libraries with multiple header files it is common to put them in a directory such as /usr/include/suricata and in fact we already do that. But are not setup for allowing includes like:

#include "suricata/filename.h" 

which would be ideal, as currently you have to do:

#include "filename.h" 

with a "-I/usr/include/suricata", and this leaves us open bring in the wrong include file, as these filenames can be rather generic.

While I have updated our libsuricata-config --cflags to allow for #include <suricata/filename.h>, this does mean that Suricata now has to be installed before a plugin can be built. And most systems like this generally allow for plugins to be built by pointing to the source directory.

The fix would be to move the source, or at least the header files form ./src to ./suricata. It is pretty common for autoconf library projects to use the library name as the source directory instead of a generic src for precisely this reason.

Examples:
- libhtp: places all source and includes in "htp"
- curl: public includes in "include/curl", lib in "lib/" and binary in "src/" (a little harder for us with trying to retrofit a library interface)
- Modern CMake guide, very much like curl (https://gitlab.com/CLIUtils/modern-cmake): "./apps/suricata.c" as the program, "./src" as the library sources and "./include/APP_NAME/" for the public includes