Adds CI to restrict types in a file (#24694)

* LETS GAMBLE!

* oops

* even more oops

* alright lets fuckin do it

* real names please

* comment

* Contributing.md update

* maybe someone will find this todo

* actually lets make it a define so people can't mistype it

* review

* changes

.github/CONTRIBUTING.md

@@ -586,6 +586,26 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples
 
 - Files and path accessed and referenced by code above simply being #included should be strictly lowercase to avoid issues on filesystems where case matters.
 
+#### Modular Code in a File
+
+Code should be modular where possible; if you are working on a new addition, then strongly consider putting it in its own file unless it makes sense to put it with similar ones (i.e. a new tool would go in the `tools.dm` file)
+
+Our codebase also has support for checking files so that they only contain one specific typepath, including none of its subtypes. This can be done by adding a specific header at the beginning of the file, which the CI will look for when running. An example can be seen below. You can also run this test locally using `/tools/ci/restrict_file_types.py`
+
+```dm
+RESTRICT_TYPE(/datum/foo)
+
+/datum/proc/do_thing() // Error: '/datum' proc found in a file restricted to '/datum/foo'
+
+/datum/foo
+
+/datum/foo/do_thing()
+
+/datum/foo/bar // Error: '/datum/foo/bar' type definition found in a file restricted to '/datum/foo'
+
+/datum/foo/bar/do_thing() // Error: '/datum/foo/bar' proc found in a file restricted to '/datum/foo'
+```
+
 ### SQL
 
 - Do not use the shorthand sql insert format (where no column names are specified) because it unnecessarily breaks all queries on minor column changes and prevents using these tables for tracking outside related info such as in a connected site/forum.
@@ -679,7 +699,6 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples
 
 ### Other Notes
 
-- Code should be modular where possible; if you are working on a new addition, then strongly consider putting it in its own file unless it makes sense to put it with similar ones (i.e. a new tool would go in the `tools.dm` file)
 - Bloated code may be necessary to add a certain feature, which means there has to be a judgement over whether the feature is worth having or not. You can help make this decision easier by making sure your code is modular.
 
 - You are expected to help maintain the code that you add, meaning that if there is a problem then you are likely to be approached in order to fix any issues, runtimes, or bugs.

.github/workflows/ci.yml

@@ -48,6 +48,7 @@ jobs:
           python tools/ci/unticked_files.py ${GITHUB_WORKSPACE}
           python tools/ci/illegal_dme_files.py ${GITHUB_WORKSPACE}
           python tools/ci/define_sanity.py
+          python tools/ci/restrict_file_types.py
           python -m tools.ci.check_icon_conflicts
           python -m tools.ci.check_icon_dupenames
           python -m tools.maplint.source --github