# Grouping items by kind if they only have documentation

Items like constants or functions have their own page, which only contains their documentation. It's fine, but when you have crates like `libc` or `stm32` which have A LOT of such items, the impact on the documentation size is huge. So instead of keeping them all in their own page, we would group them by kind in the same module (so `a::b` and `d::e` would not be in the same page).

This change would impact:
* macros (page would `macros.html`)
* attribute macros (page would `attribute-macros.html`)
* derive macros (page would `derive-macros.html`)
* functions (page would `functions.html`)
* constants (page would `constants.html`)
* statics (page would be `statics.html`)

An anchor would be generated for each item so they can be targeted (and therefore automatically scrolled to) when arriving from external links or from search.

# Render documentation for more items

The following items don't have their documentation rendered (I might have forgotten some):

* non-inlined re-exports
* `pub extern {crate}` items

This is an incoherence in regard to the other items: we show them in the generated documentation, but do not generate a page for them, so if the item has a doc comment, it's ignored currently.

With the first suggestion to group items by kind, I think it would nicely reduce the impact to the generated docs while also removing this incoherence.