PLL generated clocks and timing constraints

In general, all timing is traced back to the top-level I/O. You can do some things to avoid this(like creating master clocks inside the device), but in general this is not recommended.

The output of the PLL is based on the input clock that feeds it, which comes from a pin(usually). So your Tco is from that input pin to the output pin. For example, if you had two compiles and one had a 1ns delay from the pin to the PLL, and the second one had a 5ns delay, the data's Tco would be considerably different. If you're in a situation where that delay "cancels out", i.e. you just care about a bunch of output pins related to each other, then it will cancel out when using the input pin too.

As for the second item, sort of. Basically you've got a delay from the pin to the PLL that is uncompensated for, so static timing analysis will show this. Note that it will change with PVT. But there is no direct report for this, as it doesn't really matter in a timing analysis perspective. If you do a timing requirement(like a clock constraint or a Tco), then that delay will be used in the calculations, and if you're curious what that delay is, then do a List Paths on it and you can see all the details. (I'm assuming you're using the Classic Timing Analyzer). If you use TimeQuest, you can probably do things like report_net to directly get this info, but the basic principle that it is accounted for in your constraints still holds true.