State Pattern for traffic lights
Design

This sort of design isn't necessarily a bad thing, but in this example it's making things a lot more complicated, without providing any benefits:


ChangeLight suggests that null is not a valid state, but your TrafficLight class does not prevent its state from being initialized or set to null.
It's possible to create classes that inherit from State or one of your other state classes. This essentially means that there are an infinite number of possible states (PurpleState, RandomState, SchrodingerCatState, ...). That makes it unclear how exactly your traffic light is meant to be used.
Those state classes don't contain any actual state - it's only their type (and functionality) that matters. In that case, you might as well create static instances that can be reused. And because they all contain essentially the same logic (just different values), you don't really need separate classes either.
Methods like AllowTraffic and StopTraffic(TimeSpan delay) are probably more useful than a ChangeLight method that doesn't say anything about what the next state will be. But supporting such methods with logic inside those state classes alone is cumbersome.


Using a simple enum instead makes things a lot easier: there's no null to worry about and it's immediately clear what all the possible states are. The light-changing logic is fairly simple, so that can easily be kept in TrafficLight itself.

Further considerations

Different countries use different light patterns, and traffic lights may have different modes (such as daylight versus night, or an error state). In other words: red is not always followed by green - in some countries there's an orange-red state in-between, in some modes a light is flashing red continually, and so on.

With such requirements, the current light doesn't tell us everything about the traffic light's internal state. It would be more useful to treat each pattern as a different state. But even then I wouldn't create separate state classes with their own logic: a single data-driven class and some state-tracking logic inside TrafficLight itself should be sufficient.

Other notes


That Console.WriteLine is obviously some left-over test code, but be careful not to leave it lingering around. There's no reason why this code should depend on the presence of a console. If you're using Visual Studio, you may want to use tracepoints instead (breakpoints with a logging action). They're more flexible and don't clutter the code.
Comments like // Gets or sets the state are of no use: they're just stating the obvious, and they can only cause confusion when they become out-of-date.
State is a very generic name - TrafficLightState or TrafficLightColor may be more appropriate here.