charm: refactor URL vs Reference

This is a breaking change, so move package path to charm.v3.
I think the situation isn't quite so similar. With series, we know that there are going to be more every year, and there is no specific logic around individual series (note also: we only need to store the LTS series in a table). By contrast, the set of possible schemas here are explicitly documented (under the URL.Schema field) and there is specific logic pertaining to each one. If we were to make the logic more general, I would agree, but I don't think moving them to a separate table is much of a win in this case. It would make it look as if changing the table would change the possible schemas, but the change needed for that would actually be much bigger.