ensure SERVICE_VARIANT set; pass theme to coffeescript;

This enables theming with paver (PR #3075), mirroring similar changes as for rake in PR #2387.

In particular, when the following are set:

```
edxapp_theme_name: stanford
edxapp_theme_source_repo: https://{{ COMMON_GIT_MIRROR }}/{{ THEME_ACCT }}/edx-theme.git
edxapp_theme_version: master
edxapp_use_custom_theme: true  # false to disable & use std. theme
```

then:

```
paver devstack lms
```

will correctly read and pass the paths to both `coffee`  and `sass`.

Alternately, the process described in the comment of https://gist.github.com/yarko/8818633  is another way to test this (change a setting in `build-version.yml`, then run vagrant provision).

#### This PR corrects two deficiencies:

 *  no SERVICE_VARIANT set: 
    * prevents tasks from reading the appropriate /edx/app/edxapp *.env.json file;
    * FIX (pavelib/utils/env.py):
      * parse command line args for one of 'lms' or 'cms' or 'studio', and set SERVICE_VARIANT appropriately;

 *  coffeescript path not update with theme (once vars read from *.env.json):
    * FIX (pavelib/assets.py):
      * add theme path, when appropriate, to the search path for `coffee`;

#### Dubious code:

Please review the following aspects:
  - env.py:  class variables set at class level (not instantiation level), because of current use, e.g. Env.REPO_ROOT
     - if use case exists: single command line instance of paver, with multiple tasks - then this could confound proper operation;

 - assets.py:
   - for no particularly good reason, COFFEE_DIRS and THEME_SASS_PATHS set at module level (not w/in function;  not sure I like this.

### Goal

My goal and intent is to have `Vagrantfile` and `update` both honor `build-version.yml` files as extra-vars. At that point, a developer's *Getting Started* guide to Open edX will be an easier thing to write.  This PR is part of simplify getting started, and maintaining edx instances, since common configurations will not require "deep" repository involvement.  `Build-version.yml` is consistent with and distinct from `server-vars.yml` (server configuration and settings).

This goal will involve a PR in the configuration repository (w.i.p.) to update the various `Vagrantfile` instances, and the `update` script template.

It is conceivable that at some point a `app-settings.yml` may prove useful, although I do not have a direct-line of sight on a use-case for that.

Would you please review, @jzoldak & @singingwolfboy