* Rewrite Atom generation from stream entries to use Ox instead of Nokogiri::Builder

StreamEntry is now limited to only statuses, which allows some optimization. Removed
extra queries on AccountsController#show. AtomSerializer instead of AtomBuilderHelper
used in AccountsController#show, StreamEntriesController#show, StreamEntryRenderer
and PubSubHubbub::DistributionWorker

PubSubHubbub::DistributionWorker moves n+1 DomainBlock query to PubSubHubbub::DeliveryWorker
instead.

All Salmon slaps that aren't based on StreamEntry still use AtomBuilderHelper and Nokogiri

* All Salmon slaps now use Ox instead of Nokogiri. No touch from status on account

slightly optimized FanOutOnWriteService again

make regeneration worker unique, (only schedule/execute once at a time)

add ability to open status by URL from search (fix #53)

Returns accounts, statuses, hashtags arrays

adjusted to allow choosing it, yet

about them would be processed only after the entire status is processed

Add ability to search accounts by display name

make status pagination headers generation more lax about next page
existing

upon un-reblogging. Check if the reblog was in the feed in the first
place. It might have been filtered on distribution.

of mix of video and images in status, just wasn't rendering
the show action. I moved the validation before the status creation

Moved validation to services/post_status_service.rb

in case of debugging incoming salmons. Add <thr:in-reply-to /> to favourite
salmons because it seems to be required by GS.

StreamEntry model. Simply render Salmon slaps as they are needed

if account lock info was up to date, otherwise re-do the FollowService
with now updated information

status is not in the system at time of distribution; fix #607 - reset privacy
settings to defaults when cancelling replies

Try to fix Travis CI setup

overshadow requirement for remote-lookup

FanOutOnWriteService. The only recipient-specific part on them
is reblogged/favourited. But since only newly created statuses
appear on them, it is safe to assume that both attributes would
be false

redis-backed "mentions" timeline as redundant (given notifications)