lib: include files using known path

[bagder]

by including headers using "../[header]" when done from C files in subdirectories, we do not need to specify the lib source dir as an include path and we reduce the risk of header name collisions with headers in the SDK using the same file names.

Ref: #16949

[bagder]

@vszakats @icing what do you think about this? This PR makes it a little clearer where include files come from and it reduces the risk of problems with external files having the same names (see #16949) but it adds quite a few ../ into the source files that may feel a little "cluttery".

Personally I think I lean towards this being a small improvement

[testclutch]

Analysis of PR #16991 at 6c53a560:

Test 3023 failed, which has NOT been flaky recently, so there could be a real issue in this PR.

Generated by Testclutch

[vszakats]

The issue this sprung from seems theoretical or artifical even, but,
seeing this change, and how it makes the build setup simpler,
it seems useful to me. While also fixing the theoretical issue.

Suggestion to sync-up this change with cmake builds:

--- a/lib/CMakeLists.txt
+++ b/lib/CMakeLists.txt
@@ -36,10 +36,7 @@ list(APPEND HHEADERS "${CMAKE_CURRENT_BINARY_DIR}/curl_config.h")
 
 # The rest of the build
 
-include_directories(
-  "${PROJECT_BINARY_DIR}/lib"  # for "curl_config.h"
-  "${PROJECT_SOURCE_DIR}/lib"  # for "curl_setup.h"
-)
+include_directories("${PROJECT_BINARY_DIR}/lib")  # for "curl_config.h"
 if(USE_ARES)
   include_directories(SYSTEM ${CARES_INCLUDE_DIRS})
 endif()

[icing]

I like it. It's more clear.