rename internal to internals for subproject

Makefile

@@ -39,7 +39,7 @@ collections: $(TARGET_DIR)
 		../$(SRC_DIR)/lfc/collections/set.c          \
 		../$(SRC_DIR)/lfc/collections/str.c          \
 		../$(SRC_DIR)/lfc/collections/vector.c       \
-		../$(SRC_DIR)/internal/collections/__mapbucket.c
+		../$(SRC_DIR)/internals/collections/__mapbucket.c
 
 utils: $(TARGET_DIR)
 	cd $(TARGET_DIR) && $(CC) $(LFC_CFLAGS)  \

README.md

@@ -7,7 +7,7 @@ Consider `lfc` something like an external "standard library" for C, implementing
 ### Contents
 The contents of this repository are organized mostly the same as a typical C project: headers in `include/`, source files in `src/`, & build files in `target/`. The project is split into 3 subprojects:
 * The main `lfc` project: this is where the public interface of the library is implemented. For third-party users, this is what you interact with & have direct access to.
-* The `internal` companion project that implements any internal-use only functionality. The point of this project is to make explicit the public and private API of the library, without needing to resort entirely to something like a naming convention. Anything in this subproject is not guaranteed to be stable, because it's intended for internal use only, so third-party users should _never_ rely on the stability of this interface. It may (and likely will) change significantly between versions.
+* The `internals` companion project that implements any internal-use only functionality. The point of this project is to make explicit the public and private API of the library, without needing to resort entirely to something like a naming convention. Anything in this subproject is not guaranteed to be stable, because it's intended for internal use only, so third-party users should _never_ rely on the stability of this interface. It may (and likely will) change significantly between versions.
 * The `tests` project that provides a general framework for running unit tests. Note, however, that tests are actually implemented in the `lfc` subproject (see any `tests` directory for the corresponding test suites). There's a certain amount of natural coupling between the `lfc` and `tests` projects, and there's really no good way to solve it -- no matter how you implement it, `tests` will have to have intimate knowledge of `lfc` to know what to test.
 
 ## Installation & Use

src/internal/collections/__mapbucket.c → src/internals/collections/__mapbucket.c

@@ -1,4 +1,4 @@
-#include "internal/collections/__mapbucket.h"
+#include "internals/collections/__mapbucket.h"
 
 #include "lfc/utils/mem.h"
 #include "lfc/utils/pair.h"

src/lfc/collections/map.c

@@ -3,7 +3,7 @@
 #include <stdint.h>
 #include <stdlib.h>
 
-#include "internal/collections/__mapbucket.h"
+#include "internals/collections/__mapbucket.h"
 
 #include "lfc/collections/array.h"
 #include "lfc/utils/pair.h"