Backticks in ObjectName argument to DESCRIBE fails to parse, dialect behavior specialization

The library cannot currently parse this under the generic dialect:

```
DESCRIBE namespace.`table`;
```

I tried making my own dialect that added backticks to the delimited identifier characters, but it's not actually possible to make that work with the library modified as-is.

The reason is because of code like this that special-cases behavior based on known vs. unknown dialects:

https://github.com/sqlparser-rs/sqlparser-rs/blob/6c8f31c367ac75ea29be030bad244c0c6a2fafee/src/parser.rs#L4388

When I define my own dialect, I hit this fallback case and it fails on _many_ examples that worked fine with the GenericDialect:

https://github.com/sqlparser-rs/sqlparser-rs/blob/6c8f31c367ac75ea29be030bad244c0c6a2fafee/src/parser.rs#L4427

This is deeply problematic. The trait API gives me no way to identify my dialect with a family or type of dialect that I can tell. This means that as soon as I want to do something as simple as extending the GenericDialect with an extra identifier delimiter, all my tests start failing for reasons that were initially mysterious.

Here's the temporary hack I'm using to work around the problem:

https://github.com/bitemyapp/sqlparser-rs/commit/96c9b0df314821e5a285fb090afc629218aa2049#diff-5638cd35d93e9e77be12ed5b86d621439eb7ed698fd2eba0e8a496a9b8ba208cR60

I am willing to submit a patch to rectify this but I am fairly bothered by the `dialect_of!(…)` stuff. Is there a way to make my custom Dialect be identified as a library-defined dialect? I don't think I can override that `impl dyn Dialect` method as `dyn Dialect` is a type and not a class of types with a trait in common. Please let me know if I am wrong.

Would you mind if I submitted an MR to hoist that machinery out of the dyn/Any hack into a trait method with a default that preserves the existing behavior. I'm open to alternatives, especially ones that involve less work, as well.

Start in src/parser.rs around the linked lines 4388 and 4427, then compare the GenericDialect behavior with the custom-dialect workaround commit. Determine how dialect specialization should preserve generic parsing while accepting DESCRIBE namespace.`table`; done should include a resolved API direction and regression coverage for this case.

Written by the indexing model from the issue text.