Table/issue 2868

This finishes up @cherti's original PR at #3055 by rebasing on master and updating to work on master.  I also fixed a few bugs and reformatted the code a bit.  After I submit this PR I'm probably going to rebase again to collapse down some of @cherti's original commits, but will still make sure they get credit.
Actually with the immediate check I think I agree. With the original setup (where the Exception was raised upon printing and the format was accepted in every case), I think a TypeError is indeed the more intuitive way as this error results in a type mismatch. Presenting a ValueError here might have led to confusion as the inner details of astropy are not (and should not be) exposed or necessary to know. From an outside, when I call print on the column, the definition of a ValueError is simply not fulfilled on the level of code the user is using astropy. It is instead an internal detail not to be exposed.
Therefore, from the problem's description, I think changing it to TypeError makes sense, doesn't it? (if so, I think the TypeError should be kept for exceptions raised upon printing.)

Now, with the getter-setter-setup, which came up afterwards, I think you are right as the exception thrown should not be propagated upwards but changed to a ValueError, because here we really have a ValueError in a form that's obvious to the user.