Restructure security compliance controls

This is a first proposed iteration for how to restructure the security compliance controls page and related guidance pages.

Problem:

Currently, the security controls handbook page is likely only meaningful to security compliance professionals. If someone comes to this page that doesn't already know what our team does they would be unlikely to gain new information.

Additionally, the individual GCF control pages are a reflection of the compliance repo guidance documentation so any time we update one, we are forced to update the other. This lack of a single source of truth makes updating documentation a burden.

Goals:

1. Make the GCF controls more "self-serve"/easily consumable and provide additional context on what controls are and why they are important
2. Make a distinction between what some other companies are doing in this space vs. the GitLab approach
3. Turn the GCF control pages into the single source of truth for all non-confidential information for each GCF control
   • If we can achieve the above goal, then we can also eliminate the compliance repo guidance documentation
4. Drive any confidential information into Epics and Issues to reduce the maintenance overhead of this information