Automatically line-wrap output

Includes the following changes to Console.js:

- Console.info, Console.warn, Console.debug and Console.error now automatically
  line-wrap the output to 80 characters, or the width of the terminal screen (if
  known). This is in line with our current style guide on how things should be wrapped!

- Sometimes, there are parts of text that we don't want to line-wrap. For example, if we are
  telling the user to run 'meteor long-command --with --options' we don't want to
  have a newline in the middle of that! Wrap those commands in Console.command, like
  this:
     Console.info("something and then run", Console.command(command), "and then");
  This also makes them bold if chalk is on, as a nice bonus. So, if we ever turn
  chalk back on, the bolding of commands will be more consistent.

- Sometimes, there is bulkier output that we don't want to format at all, including
  line-wrapping: log snippets, stack traces, JSON output, etc. In that case, we can use
  Console.rawInfo, Console.rawError, Console.rawWarn and Console.rawDebug. Don't use
  Console.command inside the raw* functions! It won't be processed (at all).

- There are fancier things that we can do, other than just simply wrapping things.
  We can indent:
  "  Start here and then when wrapping
     continue over here".

  We frequently do this for commands, for example. In the past, we did this manually --
  but we can't do this for long messages that might get wrapped, and anyway, it is
  good to codify this instead of counting spaces. Allows us to be better about consistency,
  for example.

- We can also add a bulletPoint, which is a small notice in the beginning that looks like
  this:
  " => Start here and then when wrapping
       continue below the bulletPoint".

  Since it is a elss intuitive option, I have wrapped most of the time that we use a
  bulletPoint into helper functions on the Console.js.

- Some common bulletpoints that we use are:
    ASCII Checkboxes (Console.success)
    ASCII X-s (Console.failWarn and Console.failInfo)
    =>  (Console.arrowError, Console.arrowWarn, Console.arrowInfo)
    WARNING (Console.labelWarn)

  The => are sometimes indented, so they take an optional indent argument, showing how
  many spaces to indent by.

The wrapper interface would be less complicated, if there was a more unified conceit behind our
terminal messages. If there is one, it is not documented. My hope is that, in many cases,
moving these to Console will make it easier for someone with great product sense to
clean up our terminal messages. It will also make it easier to write such messages, since
it will be easier to follow an accepted standard.

In the codebase outside of Console:

- Went through and looked at our use of Console.error/info/etc, replacing with rawError/etc
  whenever approporiate.

- Went through and modified most of 'stdout' and 'stderr' calls to use the new functions.
  I made an exception for stuff that doesn't want a new line at the end, or otherwise does
  weird things (ex: print user logs directly), on the basis that, at this juncture, it is
  better to be safe than to be sorry.

- Long messages no longer need to break the code style guide by ignoring indentation rules.
  Fixed that where approporiate.

- Fixed the tests! A number of our stock messages are actually longer than 80 chars.

- Personal favourite: The Android license agreement is now line wrapped! Much better experience.

- There is some more work to do on:
  - longform help (currently comes with built-in linebreaks, would have to change the entire
    mechanism for how that works)
  - Buildmessage sometimes has headers that start with =>, but they are short. I didn't want to
    pass wrapper options all the way to main.captureOrExit before merging the rest of this and
    making sure that we like it. Since these messages are fairly short, I don't think that's
    likely to be a serious problem.

I hope that this makes life easier for us in the future! No more counting chars, no more breaking
the style guide. Better experience for users with wider terminals (or even shorter terminals!).
Let's give this a try.
do not automatically print a newline

Raw print functions should not actually print a new line -- that's
an example of processing that we should be doing in the non-raw functions.
As such, _print should not add a new line at the end!

This means that other functions that DID intend to end a new line should add
one manually. Also, a minor refactor to have less repetitive code in the wrapping functions.
Everywhere that we call a raw function, add a new line
eliminate legacy stdout.write and stderr.write functions from Console

Now that we no longer have an automatic newline on printing, we don't have to support
the awkward legacy functions that the Console used to provide. Eliminating.
responding to minor fixes on 3232

- Wrapping URLs in Console.url. Making Console.url not word-wrap URLs,
on the off-chance that a URL could be wrapped.

- Creating a doNotWrap function on the Console. Call this on things that
are not commands or URLs, but still should not be wrapped.

- fixing minor mistypes, removing a comment about the dev bundle on the
Windows branch.
minor cleanup

- renamed an argument from 'opts' to 'options' in the comments as well.
- fixed some forgotten quotes.
Fixed some mistypes
for URLs replace spaces with %20 instead of just taking care to not wrap them
adding extra line breaks to some cordova output

Glasser thinks it looks better with more newlines. I am not sure that's true --
but it looks kind of stern either way, so might as well add them in.
introducing and using Console.directory

I think that this makes the API too complicated, but we might want to treat
directories the same way that we do commands (use some chalk when needed,
do not wrap, etc). This introduces the Console.directory function.

Of course, it is not really clear to me what happens if a directory is inside a command.
(ex: 'cd <directory>'). Right now, there is no difference. It makes sense to me that
we might want to keep the entire command the same style, so I am not wrapping those
in additional Console.directory units for now.
rename doNotWrap to noWrap in console.js'
automatically escape spaces when printing directories

Directories should not wrap, but, also, we should make sure to automatically
escape spaces ("/ab/a\ b.js" vs "/ab/a b.js"). Because we might need to deal with
user input, we don't know if the user has already escaped the spaces before getting
the string. As such, we should only escape spaces that haven't already been escaped.
remove the extra Warning sign
fix some newline breaks
rename Console.directory to Console.path, do not escape spaces

Rename Console.directory to Console.path.

Do not attempt to automatically escape spaces in file paths -- it is
hard to define a function that does this only sometimes, rather than all
the time. This is something that we could change later, once we have a better
idea of when we use it.
change to the right slash
Merge pull request #3232 from meteor/word-wrap-final

Automatically line-wrap output