[ENHANCEMENT] Allow reset of Baseline Status and Browser Feature Availability

[jcscottiii]

Is your feature request related to a problem? Please describe.
There are two use cases that need to be handled:

1. Sometimes a feature may be marked as baseline and that status needs to be revoked
2. Sometimes, a feature may be marked as available in a browser but that needs to be changed

Both cases happened during this PR: mdn/browser-compat-data#23401

The parse-html-unsafe feature was previously marked as available in all browsers (which then gave it baseline status). However, that changed and the system partially handled it. The status was set successfully to not baseline but the baseline low date did not get reset. Additionally, the browser that had the feature availability removed, still had an availability date in our system. Even after ingesting this data from web features.

Describe the solution you'd like
For baseline status, given there's always a baseline enum passed in, we need to only allow the low and high dates to be set to nil by taking in the passed in value. Currently, we only allow the values to be changed from a non nil value to another non nil value:

webstatus.dev/lib/gcpspanner/baseline_status.go

Lines 116 to 117 in fbf9532

	existingStatus.LowDate = cmp.Or[*time.Time](status.LowDate, existingStatus.LowDate)
	existingStatus.HighDate = cmp.Or[*time.Time](status.HighDate, existingStatus.HighDate)

For browser specific availability:

• in extractBrowserAvailability, we need to handle the nil cases for each browser. so that we return an additional collection of availability dates to delete.
• add a new method to lib/gcpspanner/browser_availabilities.go to delete each entry in that collection if exists.
  • Why delete instead of updating with a nil? This will reflect the exact state of the web features repo instead. Additionally, it will make sure any joins continue to perform correctly.
• bonus: we need to allow for upserts of browser availability like other upsert methods instead of the current insert-only method.
  • This bonus will not solve this issue but we can clearly see that dates may change and we should be able to adapt to that.