Fix how terminal size is handled in table.pprint.

This is an attempted fix for the table.pprint-related test failures reported be @crawfordsm in #1802, which are posted here:

https://gist.github.com/crawfordsm/63c4de317b92d6cd2285

What's happening is that `table.pprint` tries to determine the size of the display from the terminal, and only failing that, use the configuration values.  This broke the ability to override the width using a configuration parameter.  This bug has been hidden because normally when running in py.test, the automatic determination of the terminal size fails, since sys.stdout is redirected to a non-tty.  For some unknown reason, I believe it isn't failing on @crawfordsm's system.

The fix is to change the semantics, and add the special value of "0" to fall back to the automatic terminal size sensing, otherwise use the value exactly as in the config setting.

@crawfordsm: Can you confirm this fixes the issue you were seeing?

@taldcroft: Does this change make sense for astropy.table?
If the user sets `conf.max_lines` to something non-zero, then it seems with this logic that `max_lines` will always get set to that value, even if they call `t.pprint(max_lines=value)`.

This whole mechanism started out a bit icky with `None`, -1, and `> 0` values (I was never really happy with that).  Now adding `0` as a new special vlaue is getting truly confusing.  Is there a way to make it work with default values of `None` in the config?  I need to go for a meeting so I can't think about the logic of whether that might help.