Check for success when following gnus links

* lisp/gnorb-org.el (gnorb-org-setup-message): Previously,
  `gnorb-org-handle-mail' would try to follow a link, but regardless of
  whether the message was found or not, it would start a reply. That's
  pretty much never correct, so check for that and bail if the link is
  stale.
Register sent messages so we can view them later

When using gnorb-org-view on a subtree, it previously only scanned for
gnus links to show in the nnir buffer. But we'd really like to see our
sent messages as well, ie the ones which are recorded in the
GNORB_MSG_IDS property. The registry is currently the most reliable way
of doing that, so we go to some lengths to make sure sent messages are
stored in the registry, and that we can get them out again when we use
gnorb-org-view.

The current major failure is that, if we don't use a local archive
method, and our sent message come back to us via some unknown imap
group (a la gmail's [Gmail]Sent Mail), we can't find them again.

* lisp/gnorb-gnus.el (gnorb-gnus-check-outgoing-headers): When we have a
  real gcc, insert the message into the registry. Additionally, give
  entries a 'gnorb-ids key, and add that key to the
  gnus-registry-extra-entries-precious list, preventing them from
  getting pruned.
* lisp/gnorb-utils.el (gnorb-msg-id-to-link): New function that tries to
  use a message-id to find the full location of a message. Currently
  only uses the registry, but other methods could be added.
* lisp/nngnorb.el (nnir-run-gnorb): When scanning subtrees for messages
  to display, also try to pick up messages referred to in GNORB_MSG_ID
  properties, using the previous new function to find their real
  location.
Check registry-enabled only after registry is loaded

* lisp/gnorb-gnus.el: Can't reference `gnus-registry-enabled' until
  after gnus-registry.el is loaded.
Only add relevant sent messages in the registry

* lisp/gnorb-gnus.el (gnorb-gnus-check-outgoing-headers): We were insert
  all the outgoing messages into the registry, which isn't right. We
  only need relevant ones -- with gnorb-id headers. Also, insert all
  such messages, even if we don't have a Gcc group. Better an incomplete
  entry than none at all.
Split out msg-id to group/link functionality

* lisp/gnorb-utils.el (gnorb-msg-id-to-group) New function, just return
  the group.
  (gnorb-msg-id-to-link) Refactor to use the above function.
Don't add a 'group key to registry if no group

* lisp/gnorb-gnus.el (gnorb-gnus-check-outgoing-headers): Probably
  better not to leave a '(group nil) key in the registry entry.
Make hash entries for new sent-message TODOs

* lisp/gnorb-gnus.el (gnorb-gnus-outgoing-make-todo-1) Completely new
  capture TODOs, made from fresh sent messages, were not getting put
  into the tracking hash. All other codepaths led to
  gnorb-trigger-todo-action, where that was happening. Whoops.
Still trying to track outgoing messages

* lisp/gnorb-gnus.el (gnorb-gnus-check-outgoing-headers): Instead of
  relying on blanking out `gnorb-gnus-sending-message-info' when we're
  done with it, just blank it out before we use it.
(gnorb-gnus-outgoing-make-todo-1): Don't set it to nil

* lisp/gnorb-org.el (gnorb-org-add-id-hash-entry): If we're in capture,
  we need the base buffer.
Begin shift to using the registry

All the property-based stuff is still in place, as is the association
hashtable. But as a first step we're now using the registry to track
incoming and outgoing messages that are related to Org TODOs. Once this
is working and debugged, then start refactoring other parts of the code
to use this and not the hashtable.

* lisp/gnorb-gnus.el (gnorb-gnus-capture-registry): New function. When
  capturing Org headings from Gnus messages, store the Org id in the
  message's registry entry.
  (gnorb-gnus-make-registry-entry): New function. Make a registry entry
  from message headers.
  (gnorb-gnus-outgoing-make-todo-1): Manually make registry entries from
  new outgoing message.
  (gnorb-gnus-incoming-do-todo): Make registry entries from incoming
  messages.

* lisp/gnorb-utils.el (gnorb-trigger-todo-action): After sending
  relevant messages, add the Org id of triggered headlines to that
  message's registry entry.
Ignore a notes.org file

.gitignore: Ignore notes.org
Stupid typo

* lisp/gnorb-gnus.el (gnorb-gnus-make-registry-entry): It's "group", not
  "gcc"
Handle nil group values in registry entries

* lisp/gnorb-utils.el (gnorb-msg-id-to-group): Skip past nils in
  the 'group value.
Show status of relevant todo when hinting messages

It can be helpful to know the TODO state keyword of the relevant org
heading when hinting from a gnus buffer.

* lisp/gnorb-gnus.el (gnorb-gnus-hint-relevant-message): Retrieve
  current TODO state keyword of relevant heading.
Fix problems when BBDB is not present and gnorb-bbdb is not loaded.
Require gnorb-bbdb when popping up bbdb buffer

* lisp/gnorb-org.el (gnorb-org-popup-bbdb): This command can be called
  interactively, we should still guard it with a require.
Rename gnorb-org-window-conf to gnorb-window-conf

Should be saved as a more central value.

* lisp/gnorb-utils.el: Add gnorb-window-conf, and use new var
* lisp/gnorb-org.el: Remove gnorb-org-window-conf
* lisp/gnorb-gnus.el: Use new var
Use a marker in conjunction with window conf

We use gnorb-window-conf for returning from various actions. You're
not supposed to rely on that for position of point, so pair it with a
marker for finding point.

* lisp/gnorb-utils.el (gnorb-return-marker): New variable pointing at
  marker
* lisp/gnorb-gnus.el: Use it
* lisp/gnorb-org.el: Use it
Don't force id creation!

* lisp/gnorb-org.el (gnorb-org-view): Was calling org-id-get-create with
  the force argument, I have no idea why, which was screwing up tracking.
Merge remote-tracking branch 'upstream/master' into no-bbdb