Remove libged TODO item - prototype complete.

src/libged/TODO

@@ -1,28 +1,3 @@
-We should *NOT* be calling raw ged_exec inside libged itself - if we refactor
-or remove commands, we have no compile-time way to know we are breaking other
-commands.  However, there are likely cases where we will want ged command
-functionality in other commands, and we want to keep command specific logic
-inside plugins rather than having to endlessly refactor into libged proper.
-
-Idea:  Write a small scanning tool that will read through a plugin source file
-looking for ged_cmd_impl structs.  Because of how the plugin system is
-implemented, that will give us the full set of possible active commands.  Make
-scanning the file part of adding the plugin to the build.  Then from that list
-we generate a series of functions - ged_CMDNAME - that are all autogenerated
-wrappers to ged_exec, as well as a ged_cmds.h header that is build time
-generated.  (For the moment it can be just a libged private thing, but the
-issue of detecting ged_exec breakage may also be a broader one.)  Functionally,
-we will still be running the commands with ged_exec as we currently are.
-However, we should always be calling the ged_CMDNAME wrappers (which will have
-the same signature as ged_exec) in the plugin (or libged) code itself.  That
-way, if we remove a LIBGED command and we were using it elsewhere via ged_exec,
-we will get a *COMPILE TIME* breakage when the generated function associated
-with that plugin disappears.
-
-
-
-
-
 These are new command ideas for LIBGED.
 Keep them sorted alphabetically.
 They are not all vetted.