update defaults handling

[tbicr]

This library consider add column with default operation is unsafe operation, it was actual for old versions that rewrite whole table to add default. New postgres versions changes only metadata so this operation is fast and can be considered as safe except cases when column added with default and not null that is not safe operation in case of django that use default only for filling data and drop db default after migration. Also adding column with default is much efficient operation than adding column and fulfill data manually.

In django 5.0 new db_default were added that assume add column with default (using db_default) is safe both for adding column with null and not null.

So in this MR whole approach to work with defaults were changed:

• add column default null - safe operation, after migration null values can be presented in db
• add column default not null is unsafe operation
• add column db_default both null and not null - safe operation, after migration no nulls can be presented in db
• add column default for django < 5.0 and ZERO_DOWNTIME_MIGRATIONS_KEEP_DEFAULT=True - safe operation, after migration no nulls can be presented in db, provide same behavior as db_default

More details described in #62

changes:

• changed ADD COLUMN DEFAULT NULL to safe operation for code default
• changed ADD COLUMN DEFAULT NOT NULL to safe operation for db_default in django 5.0+
• added ZERO_DOWNTIME_MIGRATIONS_KEEP_DEFAULT settings and changed ADD COLUMN DEFAULT NOT NULL with this settings to safe operation for django<5.0
• updated unsafe migrations links to documentation
• updated patched code to latest django version
• improved README