How to deal with some of the dependencies?
Your are using the observer-pattern in a right way. The pattern itself is probably one of the most important ones. In PHP it is not used that much though as applications have a rather quick life-cycle. Yet good to know the pattern of course. Some minor remarks about your code though:

All methods in an interface are public, no need to repeat yourself (in interfaces).
The name Observer and Subject indicate an use-case independent use. Yet your Observer are coupled to your Weather component. Better names would be WeatherDataObserver and WeatherDataSubject.
I'd consider it standard to have at least a whitespace between the function's header and the opening bracket: registerObserver(Observer $o) {
Not sure if your WeatherData is actually a service. For me the name WeatherData indicates a set of values, not necessarily the current values. I'd probably rename it to WeatherDataService. 
notifyObserver should not be public. I don't want anyone else to trigger (possibly false positives) notifications. Better remove it from the interface too.
measurementsChanged serves no purpose yet. Replace it with notifyObserver.

Your concerns are right. If I remember the book correct, they present an alternative approach on this pattern: instead of pushing the changed values to the observers, just inform them something has changed and let them pull the new values from the subject. This changes the signature of your observer to function update(Subject $weatherData) and in the update method of your CurrentConditionsDisplay you get the new values by: 

public function update(Subject $subject){
    $this-&gt;temperature = $subject-&gt;getTemperature();
    // and so on
}


Another approach would be some event'ed one. Send an event-object about what has changed. This pushed the changes to your observers and still avoids dependencies. This approach is a bit more work though. 
This is a pattern from java user-interfaces (or any views that can update themselves). In PHP you usually don't use this pattern to update user interfaces as PHP can't update the UI :). You'd access the WeatherData directly when rendering the view. Nothing really bad about this here though. 
Fine for me from what I can see.
No. Generally there are very very very few proper uses for static methods. Static methods are completely independent from others and object internal state. Successive calls to static methods should always have the same result (and should be side-effect free), no matter what happened in the application meanwhile. Usually this applies for simple helper functions only (e.g. abs or other math. helpers). Even this could be discussed though. CurrentConditionsDisplay has some internal state though, therefore static is a no-go.