Feature gate to minimize polkadot-sdk-docs build time

[nuke-web3]

Typically in webdev and docsdev, instant rendering of HTML in "dev" or "watching" mode is possible. Sadly AFAIK rustdocs does not support this kind of workflow and requires code compilation simply to view HTML. Rendering HTML only should not require building the universe. Without any ability prior to this PR to optionally build the crates referenced in the polkadot-sdk-docs crate, you would need to have a successful build of all deps.

This PR introduces a feature gate to allow minimal HTML only development of the polkadot-sdk-docs crate independent of it's internally referenced crates, taking the startup time to open the rendered HTML for it from many minutes to seconds on my machine.

Only the docs crate now is ~35 crate deps for mermaid and docify, and building all deps is ~1716 in total.

Todo

It still takes SOOOOO long to build, even with SKIP_WASM_BUILD=1 hangs on:

• librocksdb-sys

• wasm-opt-sys

• kitchensink-runtime(build)

• does cumulus.rs need the deny internal links lint?

• Check polkadot-sdk-docs build time plot to see what crates are stalling build most https://doc.rust-lang.org/beta/cargo/reference/timings.html and try and gate them too.

[nuke-web3]

Unclear if this lint must live here, if so it may need to be feature gated as it breaks the minimal docs build

[kianenigma]

I have to inspect what is done here a bit further, but fwiw if you run cargo doc -p polkadot-sdk-docs --no-deps it is pretty fast (except for the first time) to recompile, and I doubt if it gets any faster than that as this will ignore all dependencies (again, except for the first run).

With this workflow, I do most of my writing with --no-deps, and only when I want to check my linking I will remove the --no-dep to see if all links work.

In general, if this is only an improvement on the first build, assuming you don't have any target dir cached, I don't think it is worth it.

[nuke-web3]

This is the command suggested to get the minimal docs build. I did try this again on present master, and what I was experiencing was what I think was very long linking times in the stage of building the full kitchensink runtime and node... I can't seem to reproduce now, so I agree this extra complexity isn't worth it to get fast HTML output to inspect while doing docs dev.