Improve `clone` reference page

### Contributions

- [ ] I have read the contribution docs, and understand what's expected of me.

### Link to the page on docs.getdbt.com requiring updates

https://docs.getdbt.com/reference/commands/clone

### What part(s) of the page would you like to see updated?

Feedback from the [dbt Community](https://getdbt.slack.com/archives/C0441GSRU04/p1695407295316969):

- The "clone command is useful for" section is A++. I love the way it helps me contextualize the feature and think about how I can take advantage of it. I wouldn't have thought clone -> blue/green by myself (immediately?) because of the nomenclature.
- I can't think of how cloning an object would be needed to test downstream dependencies in your BI tool. Maybe because of environments? But that's a me problem, just something in my train of thought.
- The code part of the page should have it's own header and be expanded. I'd like to see something like command A with B config will take C and make D.
- You keep talking about "zero-copy cloning of tables" data platforms(e.g. RDBMS) capable platforms. But what are they and what are they not? I assume Snowflake but not Redshift from my other knowledge, but it reads very opaque to me as is. I could understand not wanting to have to maintain a list of what databases currently support it, but I think "At least Snowflake" and/or "Not Redshift as of x/x/xxxx" could work.
- "simple pointer view" I know what you mean, though others may not. The thing I don't know from that bullet point, and can not infer on my own, is the naming the objects will get. So for instance, if I already have object X in my schema, what will the name of the object X copy at a specific state (in time) object name be?
- The link for "specified state" doesn't work.
- Feature intersection: How does this interact with versioning of models?
- This feature seems completely dependent on --state but that has limits only called out on the description of state page. And it doesn't seem to point out, but that I infer, that you have to start saving manifest files instead of overwriting or deleting them. And were any of the docs about deleting the target folder as part of troubleshooting updated?
- There will be confusion and problems around all the things that have to line up to make this work - having a manifest file that works on your dbt version that works with all the versions of everything else in your repo(see macros which I don't believe can be versioned), the same data as that state(not as snapshotted or overwritten). You have to do a lot of prep and foundation work for this to be viable and that prep has to start much before you can use this command.
- This probably needs a warning that it's an advanced feature.
- Honestly, after thinking through all of that I would not have called this dbt clone, I would have called it dbt recreate, but :woman-shrugging::skin-tone-2: Way outside the scope of a docs conversation!
- Oh! zero copy cloning == aliasing. THAT's why it would be good for blue/green deployment even though it's recreating. The word alias being on this page would help.
- "clone materialization" should be linked. When I search for "clone" in the docs I don't get anything about clone materialization. See screenshot. So now I have more questions.
- Wow, with and without --full-refresh this command is a whole other level of version issues.
- This seems like it's trying to go back-in-time, under perfect circumstances, to create a point in time materialization(or alias to) without pulling it from a snapshot. This is fascinating why this was built I'm going to have to go read the Github discussions on this.

### Additional information

For more information, you can see [this dbt Community Slak discussion](https://getdbt.slack.com/archives/C2JRRQDTL/p1695394337381419)
_No response_