Issue relativedelta midnight serialization

### Under which category would you file this issue? Airflow Core ### Apache Airflow version Airflow 3.x ### What happened and how to reproduce it? Serializing a `dateutil.relativedelta` that uses absolute time fields set to `0` (e.g. `hour=0` for midnight) drops those fields. After the Dag is deserialized, the schedule no longer snaps to midnight and keeps the base datetime's clock time instead. Root cause is in `encode_relativedelta` (`airflow-core/src/airflow/serialization/encoders.py`): ```python encoded = {k: v for k, v in var.__dict__.items() if not k.startswith("_") and v} ``` The `and v` filter treats every falsy value as "unset". That is correct for **relative** fields (`hours`, `days`, …), which default to `0`, but wrong for **absolute** fields (`hour`, `minute`, `second`, `day`, …), which default to `None`. For absolute fields, `0` is meaningful like e.g. `hour=0` means "snap to midnight". **Minimal repro:** ```python from datetime import datetime from dateutil.relativedelta import relativedelta, FR from airflow.serialization.serialized_objects import BaseSerialization delta = relativedelta(weekday=FR, hour=0, minute=0, second=0) base = datetime(2024, 1, 10, 15, 30, 45) print(base + delta) # expected: 2024-01-12 00:00:00 round_tripped = BaseSerialization.deserialize(BaseSerialization.serialize(delta)) print(base + round_tripped) # actual today: 2024-01-12 15:30:45 (hour/minute/second lost) ``` Same bug hits any path that serializes intervals via `encode_relativedelta` / `encode_interval` (Dag schedules, timetables, serialized deltas). Example Dag schedule that silently changes meaning after parse → serialize → scheduler: ```python from datetime import datetime from dateutil.relativedelta import relativedelta, FR from airflow.sdk import DAG with DAG( dag_id="example_friday_midnight", start_date=datetime(2024, 1, 1), schedule=relativedelta(weekday=FR, hour=0, minute=0, second=0), catchup=False, ): ... ``` After serialization, the absol…