Follow Semantria's naming conventions

Semantria uses similar naming for two very different API calls.
Requesting a document (what this code does), fetches the results for a
single document.  Retrieving documents fetches results for all available
documents.
Factor out document_id/2

This predicate calculates a document Id if one hasn't already been
given.
Don't tag dicts for Semantria responses

I speculated that having tags would be valuable.  I don't actually have
a use case for it yet, so leave the tag as a variable for now.  As a
consequence, I removed the one dependency on library(interpolate).
Using it would have required some singleton hacks that aren't worth it.
Semantria should always return 202 on POST

According to their documentation, the only acceptable HTTP status code
when POSTing to Semantria's API is a 202 ("Accepted").  Make that
explicit so that we don't silently proceed when something goes wrong.
Punt on testing for now

Semantria's API has no test mode.  Running tests would require a normal
API key.  Unfortunately, in that environment, API calls are quite
expensive.  For now I'll not have any automated tests.  I can add them
later if I figure out a decent way to do it.
Raise a condition on request/3 error

If request/3 encounters an error while making its HTTP request to
Semantria, raise a signal (via library(condition)).  This allows the
application that's consuming Semantria's API to decide how these kinds
of failures should be handled.  In many cases, a simple fail is enough.
In other cases, an exception is wanted.
Implement process_document/2

This high level predicate makes it easy to analyze a single document
with Semantria's API.  It blocks until Semantria has finished it's
work.
Polish documentation for release