Since there were no objections, I merged and pushed this to the private repo.

Two votes for B), so B) it is. I think that also mirrors how we use the
namespace std in headers.

If I don't hear any objections until then, I'll merge this tomorrow:
https://bitbucket.org/flogo/downward-issues/pull-requests/16/issue626/diff

Closing and reopening the namespace in the middle of options/option_parser.h is
a bit ugly, but then again, including token_parser.h in the middle of the file
is a temporary hack that should go away anyway.

I like how having the using statements in our interface headers shows exactly
what others use from this interface.

I have a slight preference for B), but since you're the one doing the work, you 
should have the last say in this :)

B) or C).

using ns::Class is mainly useful to avoid typing Class lots of times in the
following code, but here's were only going to type it once. (At least in the
large majority of cases.)

As part of issue588, we want to introduce a namespace "options". This will
require some changes in the way we currently do our forward declarations.
We could do

A) 
    namespace options {
    class Options;
    }
    using options::Options;
    // ...
    SomeClass(const Options &opts);

B) 
    namespace options {
    class Options;
    }
    // ...
    SomeClass(const options::Options &opts);

C)
    #include "options_fwd" // contains forward declaration and using statement
    // ...
    SomeClass(const Options &opts);



In the cc files everything will stay the same if we add "using
options::Options;" to the "interface header" options.h (and similar statements
for OptionParser, Plugin, Synergy).

Any preferences?