Comment 2 for bug 1439151

I think that idea is basically fine, but with a couple remarks:
- Fewer possible ways to express the same thing are better. globaldb can't prevent you from expressing conflicting information. So as pertains to this patch, what would it mean if the compiler-macro didn't exist but the :deprecated property did? The availability of (setf (compiler-macro-function)) means that it could be set to nil externally, and globaldb can't enforce it.
- globaldb mostly assumes that you never never change a piece of info - you just build up information. So if you do rewrite information, the semantics are unclear, e.g. does a new DEFUN clear the new :deprecated property? Should (setf (symbol-function 'foo)) not in the context of a DEFUN clear it?
In fact, we don't even consistently have an answer to that: see example [*] below.

Granted the coupling between the function and compiler-macro is already loose, but one more piece of state is just one more place to think about: does changing this change that? So maybe it would be nicer if the macro didn't exist, and the :deprecated info were authoritative internally to the compiler, and took precedence.

Either way, I've got a change to store docstrings correctly, and will commit that shortly.

[*] in terms of it being tricky to maintain globaldb consistency, consider the following (entered at the REPL, having nothing to do with the file compiler) which prints "2" in SBCL (and CMUCL), prints "4" in at least 3 other Lisps, and is a continuable error in another-
(setf (macro-function 'hi) (lambda (form env) `(1- ,(second form))))
(setf (symbol-function 'hi) (lambda (x) (1+ x)))
(defun f (x) (hi x))
(f 3) => either 4 or 2