Improve documentation about blocking/deactivating users

What does this MR do?

I am trying to address this comment

Hmmm - unless I'm missing something, none of the provided links seems to concisely explain what the state of a "Deactivated" user is - both in general and in differentiation to "Disabled". Without this information users who look for this "functionality" may not figure out that the product can do this and that it has positive license count implications for them and that resolving the state is a user self-service action rather than requiring admin action. Seems like that kind of documentation should be gleened from this issue and put somewhere in the docs?

Additionally, if the page https://docs.gitlab.com/ee/user/admin_area/#administering-users is the "place to start" on possible user states - none of them is adequately explained (nor are explanations linked to) as to what limitations these states place on a user and under what criteria is makes sense to change a user to one of those states.

Is that type of documentation somewhere else?

I feel these points are valid and I am trying to improve the documentation associated with deactivation and blocking of a user.

Changes

• Moved deactivation and blocking documentation to separate pages
• Tried to provide an idea of when to choose blocking vs deactivation by giving a one-liner of how it can be used by admins.
• Added links to API endpoints that can block/unblock/activate/deactivate users.
• Added more information about the characteristics of a blocked user.
• Linked the administering users page to block and deactivate pages.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team