Change base class of TimeZoneSerializerField from DJRF's Field to CharField

[mfogel]

What

• change base class of TimeZoneSerializerField from DJRF's Field to CharField
• add tests to ensure the required, allow_null, and allow_blank kwargs are all working as documented by DJRF

Why

Subclassing Field introduces some situations where it isn't clear what the correct behavior is. DJRF addressed this for CharField in their 3.0 release - let's leverage their solution here.

Closes #130

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.64%. Comparing base (bb20f86) to head (610a2c2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #137      +/-   ##
==========================================
- Coverage   99.09%   98.64%   -0.46%     
==========================================
  Files          10       10              
  Lines         222      222              
==========================================
- Hits          220      219       -1     
- Misses          2        3       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gotounix]

@mfogel
I don't think changing Field to CharField is a good solution.
And this change is a BREAKING change.
Because in TimeZoneSerializerField 's __init__ using super().__init__(*args, **kwargs), but in CharField 's __init__ it does't support *arg:

class CharField(Field):
    ...

    def __init__(self, **kwargs):

Therefore, changing Field to CharField not only loses flexibility, but also makes all existing subclasses of TimeZoneSerializerField that using *args unusable. I believe a better solution is to use a custom validator instead of changing the original default behavior to fit the DRF's parameters.