`enum` fallback design allows for silent API breakages

Consider the `WpErrorCode` implementation below:

```
fn showcase(error_code: WpErrorCode) {
if let WpErrorCode::CustomError(error_code_as_string) = error_code {
if error_code_as_string == "foo" {
// handle the "foo" error
}
}
```

If we were to add a new `WpErrorCode::Foo` variant, it'll start to fail and has to be handled as such:

```
fn showcase(error_code: WpErrorCode) {
if let WpErrorCode::Foo = error_code {
// handle the "foo" error
}
}
```

This kind of silent API breakages are very dangerous. Our design should allow us to add more error variants without breaking the existing implementation.

---

The same issue can be seen in other `enum` fallbacks as well. For example, if we were to add a new variant to `PostTypeCapabilities`, it can break the same way.