simplify Event#url normalization.

Back at it with a simple little refactoring, here.

* Avoids magical AR lifecycle hooks
* Increases locality
* Only runs when url is set
* Replaces regex with semantically-identical and easier-to-grok #include? statement.

Well... nearly identical. Strings starting with "://" will match now, and they wouldn't before. Close enough. ;)
My thinking is that `/^[\d\D]+:\/\//` is equivalent to `/^.+:\/\//`, and `include?("://")` is equivalent to `/^.*:\/\//`. So this change is only the semantic difference between `/^.+:\/\//`, and `/^.*:\/\//`. This difference means that strings starting with "://" would not be prefixed now, and before they would. Given that either case would result in an obviously invalid URL, I don't think that this difference is meaningful for our use-case. So, assuming that both are semantically acceptable, I figured that `include?("://")` is much easier to read and reason about than `/^.+:\/\//`, so I opted for the former.