BUG: preserve frequency across Timestamp addition/subtraction (#4547)
closes #4547

My second PR, on basically the same code.

Assuming people agree with my comments on #4547 (that users adding timedeltas that don't match frequencies better know what they are doing), then this would be my submission.

I'm also assuming that something is up with Travis and it is not anything I have done - nosetests passes fine for me though Travis still dies more or less at startup, while it didn't on older code. That problem is true of builds not including any code I have added, e.g. https://travis-ci.org/pydata/pandas/jobs/20167915 . Maybe something in PR #6068, or does this kind of thing happen from time to time?

you might want to take a crack at #4553

something up with Travis ATM 
 What is the `freq`/`offset` of a Timestamp used for? I think it would be cool if the offset were taken into account when printing the Timestamp.
 Not sure what you mean by "taken into account" - I can add it somewhat simply as in #4553 (just something like "freq='D'") but maybe you mean something more?

In terms of uses, in addition to the "next_calendar_quarter = current_calendar_quarter + 1" usage in #4547 (which is perhaps not advisable when one can increment by the more explicit tseries.offset objects) I see that freq is used in Timestamp.to_period(), which gets a bit of a demo in http://pandas.pydata.org/pandas-docs/stable/10min.html .
 @rosnfeld What I meant by taken into account was that when calling `str` on a `Timestamp` of `offset='M'`, it would be cool if the resulting string showed just the year and month rather than the date. This would be consistent with `Period` formatting:

```
In [29]: ts = pd.Timestamp("2014-1-1", offset="M")

In [30]: str(ts)
Out[30]: '2014-01-01 00:00:00'

In [31]: str(ts.to_period())
Out[31]: '2014-01'
```
 @cancan101 don't confuse the issue
this is repr; a period repr is currently wrong as well and needs to be fixed

a repr is something that can be copy pasted to reverse the object

this is not pretty-printing 
 @jreback I understand repr and str are not the same. I was just suggesting that it would be cool for the `str` formatting of Timestamp to take into account the offset when deciding how to format the TImestamp.  
 no problem with that. can you propose some possibilities (e.g. Timestamps / Periods with and w/o freqs for various freqs)
 @rosnfeld can you rebase on current master and force push....had some issue with caching of some deps...shouldl be resolved now
 Yup, done and Travis seems happy now.
 @rosnfeld thanks again!

don't be shy about looking for more PR's!
 @cancan101 - I played with your suggestion a little bit as it sounded cool, but after working through some examples I'm not sure I am in favor of it. In my understanding, Timestamps represent an instant in time, whereas Periods represent a span of time, and I think we should present these differently to users.

One may have monthly samples of some quantity, but if it's actually a point-in-time sample, taken at say the end of the month vs the start of the month, I think I'd like to see that daily level of detail rather than just seeing the month. If one instead is working with some quantity averaged over the month (e.g. average temperature over a month) then it makes more sense to just show the month, but then I think one should be using a Period rather than a Timestamp.

Admittedly I haven't played with Periods much, I've just read about them in the Python for Data Analysis book.
 @rosnfeld What you say makes sense. That being said, why does the Timestamp even have an offset to begin with?
 @cancan101 Right, good question - I think it's because a Timestamp really can have a "frequency", it's an instant-in-time sample taken every so often. I don't think pandas does too much with this information at present.
 The freq on a Timestamp facilities operations w.r.t. that frequency, e.g.

e.g.

`Timestamp('20130101',offsets=pd.offsets.Second())+1`
