Consider documenting asserts/guards separately

[martriay]

Currently there's many guard functions (e.g. assert_only_owner, assert_only_role, etc) analogous to solidity modifiers.

Currently they're documented as simple internals, evaluate if there's value in grouping them in the API docs in their own category.

[martriay]

i think either way they should be under internals since they share the same overall status: they're not externals. maybe they can have their own subgroup as impls do in externals.

[ericnordelo]

I was playing with this and tried different options:

• A separate category at the beginning of the component doc page. This doesn't seem right since the functions are placed under the Internal implementation, and the benefit of the added category doesn't overcome the inconsistency it generates.
• A separate section under internal implementations. This doesn't seem right since there's no extra implementation, and moving something like assert_only_owner alone to a different implementation didn't feel right either.
• A separate NOTE in the docsite at the beginning of the component section. This doesn't look that bad, but I don't prefer it over what we have now, since we have already notes and mentions to these guards a lot for example in Access API Reference, and I wouldn't refactor the full page to add this entry.

After playing with how these different options look, I lean towards keeping what we have now. The option that was the better to me was moving the "modifiers" to a separate implementation, but I rather keep them under Internal Implementation unless we define and write down exactly what a "modifier" is, and move them into a separate internal implementation. I don't think is worth prioritizing this though, since these guards are well-documented already.

Closing the issue now. We may open a different more specific one if we decide to define and write these extra implementations at some point.