[MDB Ignore] [IDB Ignore] Kills off /obj/item/device (#21774)

This has zero reason to exist in our code base. We have no procs or
variables tied to this. I removed it to make future modifications
cleaner.

---------

Signed-off-by: Cody Brittain <1779662+Generalcamo@users.noreply.github.com>

.github/CONTRIBUTING.md

@@ -1,4 +1,5 @@
 # Licensing
+
 Aurora Station code is licensed under the [GNU Affero General Public License version 3](https://www.gnu.org/licenses/agpl-3.0.en.html), which can be found in full in LICENSE-AGPL3.txt.
 
 Commits with a git authorship date prior to `1420675200 +0000` (2015/01/08 00:00) are licensed under the GNU General Public License version 3, which can be found in full in LICENSE-GPL3.txt.
@@ -10,6 +11,7 @@ All assets including icons and sound are under a [Creative Commons 3.0 BY-SA](ht
 # GitHub Standards
 
 ### Sub-licensing External Content
+
 **When does this section apply to me?** When you are integrating content that is **not** licensed under [AGPLv3](https://www.gnu.org/licenses/agpl-3.0.en.html) (code)
 or [Creative Commons 3.0 BY-SA](https://creativecommons.org/licenses/by-sa/3.0/) (icons and sounds). The most common application here is for icons and sounds gathered
 from an external source or repository.
@@ -27,6 +29,7 @@ or within the plain text describing the change itself.
 When reading the sub-sections that follow, note that these will be **generalizations**, and the specifics will be dictated by the license itself.
 
 #### Code
+
 Code from most other open source SS13 code bases is GPLv3 or AGPLv3. This means that it's free to be copied without any additional effort. Though any notes of authorship within
 the code files, if presents, must be kept intact. Be wary of **Goon**: their code is licensed under CC-BY-SA-NC and is **not** directly compatible with our codebase's license.
 Porting Goon code directly is highly discouraged as a result.
@@ -36,6 +39,7 @@ and that a separate license file (if present in/packaged with the original sourc
 porting in this manner into a `modules/` sub folder, and stick the license file in there.
 
 #### Other Assets (Sound, Icons)
+
 If the material is distributed under CC-BY-SA 3.0, then it can go straight into the relevant folders, as long as you attribute the author(s) in the PR and changelog if they can be
 identified.
 
@@ -43,6 +47,7 @@ In any other case, create a subfolder somewhere in the relevant structure, stick
 license permits the intended use of the content in the appropriate manner.
 
 ### Peer Review
+
 All pull requests are subject to peer review prior to being merged. After said reviews, they are given a final once-over by a maintainer and
 then merged if good.
 
@@ -55,6 +60,7 @@ This is to ensure that there is enough time to review and discuss new additionsf
 A **bug fix** pull request will require **two** reviews, if it is to be merged in the first 24 hours, or **one** following the first 24 hours.
 
 ### Prefer Atomic Pull-Requests
+
 Pull requests should do **one** thing.
 
 This means that a series of small, dependant pull requests is preferred over one large, monolithic one.
@@ -65,6 +71,7 @@ Small pull requests allow for easier reverting, easier (and faster!) reviewing a
 developers in the future to more easily locate all changes relevant to a potential issue.
 
 ### Changelogs
+
 Changelogs are automatically parsed from within the `html/changelogs` folder. A readme file exists there with specific information on how to
 create and manage changelogs. All pull requests which contain player-visible changes are required to have a changelog. Any others, like pull
 requests containing background system tweaks, minor optimizations, admin systems, etcetera, do not necessarily require a changelog.
@@ -76,20 +83,23 @@ about it.
 # Coding Standards
 
 ### Absolute Pathing
+
 Absolute pathing has to be used for type, proc, and verb definitions. This is to make searching and reading easier.
 
 An example of properly pathed code:
+
 ```DM
-/obj/item/device/cake
+/obj/item/cake
 	[cake code here]
 
-/obj/item/device/cake/proc/eat_cake()
+/obj/item/cake/proc/eat_cake()
 	[proc code here]
 ```
 
 An example of badly pathed code:
+
 ```DM
-/obj/item/device/cake
+/obj/item/cake
 	[cake code here]
 
 	proc/eat_cake()
@@ -97,6 +107,7 @@ An example of badly pathed code:
 ```
 
 ### Initialize() over New()
+
 Since the implementation of the Stoned Master Controller, overrides of the `New()` proc have effectively become depracted in favour of `Initialize()` and `LateInitialize()`. In most cases, `Initialize()` is a drop-in replacement for `New()`, however, there are a few considerations to be taken into account when using this. Specifically, `Initialize()` must always return a initialization hint and must always call the superior definition via `..()`. Usually these two are done together, either via the `. = ..()` semantics or with explicit `return ..()` statements.
 
 `LateInitialize()` can be used to manage race conditions during map loading. In the middle of the game, when `mapload = FALSE` in `Initialize()`, `LateInitialize()` is called immediately after the specific atom's `Initialize()` call. However, if `mapload = TRUE`, which it does during map atom initialization, the `LateInitialization()` of an atom is called once all atoms have finished their `Initialization()` calls. Note that `Initialize()` needs to return `INITIALIZE_HINT_LATELOAD` in order for `LateInitialization()` to be called in either case.
@@ -104,9 +115,11 @@ Since the implementation of the Stoned Master Controller, overrides of the `New(
 Refer to the [wiki](https://github.com/Aurorastation/Aurora.3/wiki/Atom-Initialization) article for further information.
 
 ### qdel() and Destroy() usage
-All objects with an applicable type need to be deleted by `qdel()`, as opposed to the regular `del()` proc. While conducting this action, make sure you remove all possible references to the object you assign for deletion *after* calling `qdel()`. This will enable the garbage collector to handle the objects assigned to it at its own pace, thus reducing lag in the long run.
+
+All objects with an applicable type need to be deleted by `qdel()`, as opposed to the regular `del()` proc. While conducting this action, make sure you remove all possible references to the object you assign for deletion _after_ calling `qdel()`. This will enable the garbage collector to handle the objects assigned to it at its own pace, thus reducing lag in the long run.
 
 An example of how to use `qdel()`:
+
 ```DM
 /obj/item/plate
 	var/obj/item/cake/cake
@@ -126,6 +139,7 @@ The `Destroy()` proc for objects should be defined, if there are any special ope
 Note that any modified `Destroy()` proc must always **call its superior definition `..()`** and **must return a deletion hint.** Usually the hint passed down from the superior definition is returned, via `. = ..()` or an explicit `return ..()` statement.
 
 An example of how to define `Destroy()` for an item that needs it:
+
 ```DM
 /obj/item/plate
 	var/obj/item/cake/cake
@@ -144,39 +158,45 @@ An example of how to define `Destroy()` for an item that needs it:
 ```
 
 `qdel()` is **not** capable of handling the following types of objects:
-* file
-* savefile
-* SQLLite object
-* list objects.
-* turfs
-* areas (Note that these shouldn't be deleted at all)
+
+- file
+- savefile
+- SQLLite object
+- list objects.
+- turfs
+- areas (Note that these shouldn't be deleted at all)
 
 You will have to use the regular `del()` proc to delete any object of that type (except for `/turf`, which should use `ChangeTurf()`).
 
 More details on qdel, Garbage, and `Destroy()` are available [on the wiki](https://github.com/Aurorastation/Aurora.3/wiki/Garbage%2C-qdel%2C-and-Destroy).
 
 ### HTML styling for user output
+
 All text output to the user, specially if the output operator `<<` is used, should be formatted in proper HTML. DM text macros for styling, such as `\red` and `\blue`, are no longer to be used actively. This will enable the modification of used HTML styling later down the line, via the centralized .css files. It will also enable a switch from an output panel, to other output methods.
 
 For reference, here are the standard span classes for user output, and the correlation between them and the DM text macros:
-* `<span class='danger'></span>` corresponds to `\red` and is bold.
-* `<span class='warning'></span>` also corresponds to `\red` and is not bold.
-* `<span class='notice'></span>` corresponds to `\blue` and is not bold.
+
+- `<span class='danger'></span>` corresponds to `\red` and is bold.
+- `<span class='warning'></span>` also corresponds to `\red` and is not bold.
+- `<span class='notice'></span>` corresponds to `\blue` and is not bold.
 
 There exist pre-processor macros for using these spans. `span(class, text)` which is the equivalent of typing a string that looks like this: `"<span class='[class]'>[text]</span>"` and macros such as `SPAN_WARNING(text)`, `SPAN_NOTICE(text)`, `SPAN_DANGER(text)`. Using the SPAN_X() macros is preferred.
 
 The stylesheet available for use within DM can be found in `code/stylesheet.dm`.
 
 ### Usage of forceMove
+
 In order to make `Exited()` and `Entered()` procs more reliable, the usage of `forceMove()` when forcibly moving one item to another location, be it another item or turf, is required. Directly changing an item's loc values will skip over calls to the aforementioned procs, thus making them less useful and more unreliable.
 
 An example of improper item moving:
+
 ```DM
 /proc/some_proc(var/obj/A, var/obj/B)
 	A.loc = B	// Simply move A inside B.
 ```
 
 An example of proper item moving:
+
 ```DM
 /proc/some_proc(var/obj/A, var/obj/B)
 	A.forceMove(B)	// This will call A.loc.Exited() and B.Entered().
@@ -184,20 +204,24 @@ An example of proper item moving:
 ```
 
 ### Regarding the variable usr
+
 If at all possible, procs outside of verbs and `Topic()` should avoid reliance on `usr`, and instead use a custom argument to specify the user and its expected type. This makes it easier to reuse procs in chains where `usr` is not always defined, and combats against potential security flaws that relying on `usr` can bring.
 
 `usr` must also always be validated to be the expected type!
 
 ### Reserved argument names
+
 All BYOND procs have a set list of variables which are implicitly defined in each proc. However, the DM compiler will allow you to reuse these names as names for your custom variables. This should be avoided at all costs, to improve the readability and understanding of code.
 
 A list of reserved argument names instantiated with all procs:
-* `vars` being an alias of `src.vars` if `src` exists.
-* `args`
-* `usr`
-* `src`
+
+- `vars` being an alias of `src.vars` if `src` exists.
+- `args`
+- `usr`
+- `src`
 
 ### Avoid `in world` loops
+
 Due to the amount of instances in the world, utilizing an `in world` loop should be avoided in all instances. In large projects, specially when crawling for types that are not optimized internally by BYOND (only core built-in types are), crawling `in world` will surmount to a very large blocking loop and will almost certainly trigger the infinite loop warning. This forces the specific callstack to sleep at least once.
 
 Note that a for-each loop without an explicit container specified will default to an `in world` loop. This is to say, the following two examples are equivalent:
@@ -211,21 +235,25 @@ for (var/client/C in world)
 ```
 
 ### Database prefixing
+
 All tables for the database should be prefixed according to the following list:
-* `ss13_` for tables in which ingame data is held.
-* `discord_` for tables in which BOREALIS data is held.
+
+- `ss13_` for tables in which ingame data is held.
+- `discord_` for tables in which BOREALIS data is held.
 
 # HTML UI Standards
 
 ### UI conversion policy
+
 Due to our current situation with 5 different HTML UI systems we are now enforcing a policy that all new UIs should be made using the TGUI system. This policy also applies to editing existing UIs, with the following exceptions:
 
- 1. Modification is security / severe bug fix.
- 0. It is typo fix.
- 0. Touched UI file is too large.
- 0. TGUI can't accommodate that type of UI.
+1.  Modification is security / severe bug fix.
+2.  It is typo fix.
+3.  Touched UI file is too large.
+4.  TGUI can't accommodate that type of UI.
 
 ### Globals
+ 
 All globals must use the defines found in `__defines/_globals.dm`. This is to store globals inside the Global Controller, allowing us to view and edit them at runtime. Here are a few examples.
 `GLOBAL_VAR(thing)` will create a global variable `var/thing` accessed with `GLOB.thing`.
 `GLOBAL_LIST_INIT(list_of_stuff, list("stuff", "thing"))` will create a global list `var/list/list_of_stuff = list("stuff, thing")` accessed with `GLOB.list_of_stuff`.