res_pjsip/pjsip_options: Fix From generation on outgoing OPTIONS

res_pjsip/pjsip_options:  Fix From generation on outgoing OPTIONS

No one seemed to notice but every time an OPTIONS goes out, it goes
out with a From of "asterisk" (or whatever the default from_user is set to),
even if you specify an endpoint.

The issue had several causes...
qualify_contact is only called with an endpoint if called from the CLI.
If the endpoint is NULL, qualify_contact only looks up the endpoint if
authenticate_qualify=yes. Even then, it never passes it on to
ast_sip_create_request where the From header is set.  Therefore From
is always "asterisk" (or whatever the default from_user is set to).
Even if ast_sip_create_request were to get an endpoint, it only sets
the From if endpoint->from_user is set.

The fix is 4 parts...

First, create_out_of_dialog_request was modified to use the endpoint id
if endpoint was specified and from_user is not set.

Second, qualify_contact was modified to always look up an endpoint if
one wasn't specified regardless of authenticate_qualify.  It then passes
the endpoint on to create_out_of_dialog_request.

Third (and most importantly), find_an_endpoint was modified to find
an endpoint by using an "aors LIKE %contact->aor%" predicate with
ast_sorcery_retrieve_by_fields.  As such, this patch will only work
if the sorcery realtime optimizations patch goes in.  Otherwise we'd
be pulling the entire endpoints database every time we send an OPTIONS.
Since we already know the contact's aor, the on_endpoint callback was also
modified to just check if the contact->aor is an exact match to one of
the endpoint's.

Finally, since we now have an endpoint for every OPTIONS request,
res_pjsip/endpt_send_request (which handles out-of-dialog reqests) was
updated to get the transport from the endpoint and set it on tdata.
Now the correct transport is used.

Change-Id: I2207e12bb435e373bd1e03ad091d82e5aba011af