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 - set the above four theme settings in `build-version.yml`, then run `vagrant provision`.

A way to run this on vagrant fullstack is to use `build-version.yml`, as above, and either include it in, or symlink it to `/edx/app/edx_ansible/server-vars.yml`  (it shows up as `/vagrant/build-version.yml`), and then using `update edx-platform some-version`.

*Note: currently you will need to completely remove `edx-platform` in order to clone one from a different repository (since `git remotes` is not managed thru `update`).*

#### 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 the use case exists of a single command line instance of paver, with multiple tasks then this could confound proper operation;
     - I rather prefer having `None` base class attributes, and setting them in `__init__()`, since this would ensure proper operation.   I did not follow this path because it would have meant more code changes (no `Env.REPO_ROOT` anywhere), and would add instantiation of the class.   I prefer consensus on the approach first (so took the path closer to the current code).

  - `assets.py`:
     - for no particularly good reason, `THEME_COFFEE_PATHS` 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 will 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.

Would you please review, @jzoldak & @singingwolfboy