refactor(lib): provide doom-libs as subfeatures

This allows us to load them via doom-require. Why not use normal
features? Because Doom's libraries are designed to be loaded as part of
Doom, and will openly rely on Doom state if needed; this is a contract I
want to enforce by ensuring their only entry points are through
`doom-require` or autoloading.

I will add them to the rest of the libraries later.

Site-node: this also adds Commentary+Code to the comment headings, as I
want a space to use that space to describe the library, when I get
around to it.

lisp/lib/print.el

@@ -1,16 +1,20 @@
 ;;; lisp/lib/print.el -*- lexical-binding: t; -*-
 ;;; Commentary
-;;;
-;;; This is Doom's output library, for controlling what does and doesn't get
-;;; logged, and provides a simple DSL for formatting output. It's mainly to
-;;; serve the noninteractive use-case, as `message' is more than good enough in
-;;; interactive sessions, but `print!' and `doom-log' are safe to use as a
-;;; drop-in replacement.
-;;;
+;;
+;; This is Doom's output library, for controlling what does and doesn't get
+;; logged, and provides a simple DSL for formatting output. It's mainly to
+;; serve the noninteractive use-case, as `message' is more than good enough in
+;; interactive sessions, but `print!' and `doom-log' are safe to use as a
+;; drop-in replacement.
+;;
 ;;; Code:
-
+(eval-when-compile (require 'doom)) ; be silent, o'byte-compiler
 (require 'ansi-color)
 
+
+;;
+;;; Variables
+
 (defvar doom-print-ansi-alist
   '(;; fx
     (bold       1 :weight bold)
@@ -438,3 +442,6 @@ transformative logic."
                  (doom-print--apply (cdr forms) t)
                  nil))
         (forms)))
+
+(provide 'doom-lib '(print))
+;;; print.el ends here