Drop default=0 from concrete model foreignkey definitions

[vegu]

Not sure why they are there, none of the fields are allowed to be 0, and its quite possibly the reason AlterField migrations for those fields break when the database backend is mysql

Relates to #46

[grizz]

@peeringdb/pc This is a bug, and also a very likely rabbit hole. :) We should probably tackle it sooner rather than later however.

[shane-kerr]

+1

[paravoid]

Not sure if we need a separate task to track this, but the removal of the migrations in 7ddb49f (which was a fallout of #45, for reasons that are related to the present issue) is causing a problem, where running "makemigrations" (even on a downstream project!) creates a new auto migration under django_peeringdb that alters all the fields…