Osculp32k, Xosc32k: Remove support for a write lock

Write lock is a difficult mechanism to model. In case of a non-POR reset with
a write lock engaged, clocking initialization procedure becomes basically
undefined and types do not reflect the correct state of a hardware. Counter
increment on an `Enabled` type is not enough to model this behaviour correctly.

hal/src/thumbv7em/clock/v2/osculp32k.rs

@@ -209,25 +209,6 @@ where
     }
 }
 
-impl<X, Y, N> Enabled<OscUlp32k<X, Y>, N>
-where
-    X: Output32k,
-    Y: Output1k,
-    N: Counter + PrivateIncrement,
-{
-    /// Write lock the OscUlp32k
-    ///
-    /// Locked until a Power-On Reset (POR) is detected.
-    ///
-    /// TODO, how should we model the hardware write lock?
-    /// For now artificially raise the use counter by 1
-    #[inline]
-    pub fn write_lock(mut self) -> <Self as PrivateIncrement>::Inc {
-        self.0.token.wrtlock();
-        self.inc()
-    }
-}
-
 //==============================================================================
 // GclkSource
 //==============================================================================

hal/src/thumbv7em/clock/v2/xosc32k.rs

@@ -418,26 +418,6 @@ where
     }
 }
 
-impl<M, X, Y, N> Enabled<Xosc32k<M, X, Y>, N>
-where
-    M: Mode,
-    X: Output32k,
-    Y: Output1k,
-    N: Counter + PrivateIncrement,
-{
-    /// Write lock the Xosc32k
-    ///
-    /// Locked until a Power-On Reset (POR) is detected.
-    ///
-    /// TODO, how should we model the hardware write lock?
-    /// For now artificially raise the use counter by 1
-    #[inline]
-    pub fn write_lock(mut self) -> <Self as PrivateIncrement>::Inc {
-        self.0.token.wrtlock();
-        self.inc()
-    }
-}
-
 impl<M, X, Y> Enabled<Xosc32k<M, X, Y>, U0>
 where
     M: Mode,