Conflicts:
   src/translator/response.cpp -> Bringing to sync with ByteArray updates
   src/translator/response.h -> Bringing to sync with ByteArray updates

We however have Histories in constructor, which we will remove out of the way
soon.

…entence is happening

…entence is happening

…jp/strengthen-annotation

…e-builder

Towards #77.

Response previously required marian-deep objects like histories and
vocabs for construction. It has been decided that this structure needs
to be exposed and should not have marian-internals. This commit is the
final nail in the coffin of Response as a marian object concept. The
construction responsiblity of Response is now moved to a ResponseBuilder
class.

Towards #77.

Reduces Request to require only (Id, Segments, ResponseBuilder). Request is
an internal structure for Service and *will not be* exposed. However, the
constructor was in fact dreadful and can now be cleaned up to simplify
that ResponseBuilder nicely abstracts away the transition process from
Request -> Response.

Towards #77.

Towards #77.

We improve doxygen compatible documentation for the external API exposed
by Service. There are constructors using marian internal structures
(like Options). But there is also a provision of a string (current
Unified API subsitute for Options) based constructor and should suffice
for a client who wants to not know of marian internals.

Towards #77.

Brings in the concept of ResponseOptions, which should be the intended
outcome of TranslationRequest, providing additional options
along with the source string describing how to construct Response.

It's currently typedef-ed to Ptr<marian::Options>, and subject to change
if and when UnifiedAPI can bring it's own proper equivalent.

Through options, ResponseBuilder now has if-guards to construct
QualityScores or Alignments making it a no-op if the options are unset,
bringing in the desired feature, albeit with a reinvented wheel
structure which is not improper.

Service::translate(...) calls Service::translateWithOptions(...) now
reducing redundancy in the source-code. The default options are
configured to no-alignments and no quality-scores, bringing down runtime
by about 30s on WNGT20 set.

service-cli is adjusted to have options so the alignment and quality
tests are still functional.

Towards #77.

- What was earlier translateWithOptions is now renamed to translate,
  making it a method overload based on arguments.
- A new translateMultiple is provided, which is blocking. This allows
  the browser to sent separate vector<text> which is queued as a whole,
  but each text maps to a Request each for which there is a Response. This
  is closer to what exists in TranslationModel as of now, except there are
  speed gains from properly batching. translateMultiple accepts
  TranslationRequest as well, although it does nothing with it.

Towards #77.

This updates TranslationModel to use the new
Service::translateMultiple(...) API to efficiently pack batches by
compiling multiple Requests and using only using one translate-dispatch
call for all Requests.

Due to changes in batching/ordering and consequently difference in
approximations after quantization, the outputs are now different from those
earlier (breaking bergamot-translator-app regression-tests) but correct
nonetheless (regression-tests output now need updating).

Towards #77.

Response previously required marian-deep objects like histories and
vocabs for construction. It has been decided that this structure needs
to be exposed and should not have marian-internals. This commit is the
final nail in the coffin of Response as a marian object concept. The
construction responsiblity of Response is now moved to a ResponseBuilder
class.

Towards #77.

Reduces Request to require only (Id, Segments, ResponseBuilder). Request is
an internal structure for Service and *will not be* exposed. However, the
constructor was in fact dreadful and can now be cleaned up to simplify
that ResponseBuilder nicely abstracts away the transition process from
Request -> Response.

Towards #77.

Towards #77.

We improve doxygen compatible documentation for the external API exposed
by Service. There are constructors using marian internal structures
(like Options). But there is also a provision of a string (current
Unified API subsitute for Options) based constructor and should suffice
for a client who wants to not know of marian internals.

Towards #77.

Brings in the concept of ResponseOptions, which should be the intended
outcome of TranslationRequest, providing additional options
along with the source string describing how to construct Response.

It's currently typedef-ed to Ptr<marian::Options>, and subject to change
if and when UnifiedAPI can bring it's own proper equivalent.

Through options, ResponseBuilder now has if-guards to construct
QualityScores or Alignments making it a no-op if the options are unset,
bringing in the desired feature, albeit with a reinvented wheel
structure which is not improper.

Service::translate(...) calls Service::translateWithOptions(...) now
reducing redundancy in the source-code. The default options are
configured to no-alignments and no quality-scores, bringing down runtime
by about 30s on WNGT20 set.

service-cli is adjusted to have options so the alignment and quality
tests are still functional.

Towards #77.

- What was earlier translateWithOptions is now renamed to translate,
  making it a method overload based on arguments.
- A new translateMultiple is provided, which is blocking. This allows
  the browser to sent separate vector<text> which is queued as a whole,
  but each text maps to a Request each for which there is a Response. This
  is closer to what exists in TranslationModel as of now, except there are
  speed gains from properly batching. translateMultiple accepts
  TranslationRequest as well, although it does nothing with it.

Towards #77.

This updates TranslationModel to use the new
Service::translateMultiple(...) API to efficiently pack batches by
compiling multiple Requests and using only using one translate-dispatch
call for all Requests.

Due to changes in batching/ordering and consequently difference in
approximations after quantization, the outputs are now different from those
earlier (breaking bergamot-translator-app regression-tests) but correct
nonetheless (regression-tests output now need updating).

…ranslator into jp/response-builder

This reverts commit dbad655.

This reverts commit 666b15d.

This reverts commit 0dc0cae.

…ranslator into jp/response-builder

Well, was easy deleting a bunch of lines of code to get things to work.