docs: new and improve lexical docs, hoist up all headings (#6639)

docs/plugins/build-your-own.mdx

@@ -22,11 +22,11 @@ Our plugin template includes everything you need to build a full life-cycle plug
 
 By abstracting your code into a plugin, you'll be able to reuse your feature across multiple projects and make it available for other developers to use.
 
-### Plugins Recap
+## Plugins Recap
 
 Here is a brief recap of how to integrate plugins with Payload, to learn more head back to the [plugin overview page](https://payloadcms.com/docs/plugins/overview).
 
-#### How to install a plugin
+### How to install a plugin
 
 To install any plugin, simply add it to your Payload config in the plugins array.
 
@@ -45,7 +45,7 @@ const config = buildConfig({
 export default config;
 ```
 
-#### Initialization
+### Initialization
 
 The initialization process goes in the following order:
 
@@ -55,7 +55,7 @@ The initialization process goes in the following order:
 4. Sanitization cleans and validates data
 5. Final config gets initialized
 
-### Plugin Template
+## Plugin Template
 
 In the [Payload plugin template](https://github.com/payloadcms/payload-plugin-template), you will see a common file structure that is used across plugins:
 
@@ -63,14 +63,14 @@ In the [Payload plugin template](https://github.com/payloadcms/payload-plugin-te
 2. /src folder - everything related to the plugin
 3. /dev folder - sanitized test project for development
 
-#### Root
+### The root folder
 
 In the root folder, you will see various files related to the configuration of the plugin. We set up our environment in a similar manner in Payload core and across other projects. The only two files you need to modify are:
 
 - **README**.md - This contains instructions on how to use the template. When you are ready, update this to contain instructions on how to use your Plugin.
 - **package**.json - Contains necessary scripts and dependencies. Overwrite the metadata in this file to describe your Plugin.
 
-#### Dev
+### The dev folder
 
 The purpose of the **dev** folder is to provide a sanitized local Payload project. so you can run and test your plugin while you are actively developing it.
 
@@ -101,7 +101,7 @@ When you're ready to start development, navigate into this folder with `cd
 
 And then start the project with `yarn dev` and pull up `http://localhost:3000` in your browser.
 
-### Testing
+## Testing
 
 Another benefit of the dev folder is that you have the perfect environment established for testing.
 
@@ -129,7 +129,7 @@ describe('Plugin tests', () => {
 })
 ```
 
-### Seeding data
+## Seeding data
 
 For development and testing, you will likely need some data to work with. You can streamline this process by seeding and dropping your database - instead of manually entering data.
 
@@ -159,7 +159,7 @@ export const seed = async (payload: Payload): Promise<void> => {
 
 ```
 
-#### Src
+## Overview of the src folder
 
 Now that we have our environment setup and dev project ready to go - it&apos;s time to build the plugin!
 
@@ -188,7 +188,7 @@ export const samplePlugin =
 3. From here, you can extend the config however you like!
 4. Finally, return the config and you&apos;re all set.
 
-### Spread Syntax
+## Spread Syntax
 
 [Spread syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax) (or the spread operator) is a feature in JavaScript that uses the dot notation **(...)** to spread elements from arrays, strings, or objects into various contexts.
 
@@ -235,7 +235,7 @@ If you wish to add to the `onInit`, you must include the async/await. We don&apo
 
 In the template, we have stubbed out a basic `onInitExtension` file that you can use, if not needed feel free to delete it.
 
-### Webpack
+## Webpack
 
 If any of your files use server only packages such as fs, stripe, nodemailer, etc, they will need to be removed from the browser bundle. To do that, you can [alias the file imports with webpack](https://payloadcms.com/docs/admin/webpack#aliasing-server-only-modules).
 
@@ -251,7 +251,7 @@ config.admin = {
 }
 ```
 
-### Types
+## Types
 
 If your plugin has options, you should define and provide types for these options in a separate file which gets exported from the main `index.ts`.
 
@@ -268,26 +268,26 @@ export interface PluginTypes {
 
 If possible, include [JSDoc comments](https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html#types-1) to describe the options and their types. This allows a developer to see details about the options in their editor.
 
-### Best practices
+## Best practices
 
 In addition to the setup covered above, here are other best practices to follow:
 
-##### Providing an enable / disable option:
+### Providing an enable / disable option
 
 For a better user experience, provide a way to disable the plugin without uninstalling it. This is especially important if your plugin adds additional webpack aliases, this will allow you to still let the webpack run to prevent errors.
 
-##### Include tests in your GitHub CI workflow:
+### Include tests in your GitHub CI workflow
 
 If you&apos;ve configured tests for your package, integrate them into your workflow to run the tests each time you commit to the plugin repository. Learn more about [how to configure tests into your GitHub CI workflow.](https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs)
 
-##### Publish your finished plugin to NPM:
+### Publish your finished plugin to NPM
 
 The best way to share and allow others to use your plugin once it is complete is to publish an NPM package. This process is straightforward and well documented, find out more about [creating and publishing a NPM package here](https://docs.npmjs.com/creating-and-publishing-scoped-public-packages/).
 
-##### Add payload-plugin topic tag:
+### Add payload-plugin topic tag
 
 Apply the tag **payload-plugin** to your GitHub repository. This will boost the visibility of your plugin and ensure it gets listed with [existing payload plugins](https://github.com/topics/payload-plugin).
 
-##### Use [Semantic Versioning](https://semver.org/) (SemVer):
+### Use Semantic Versioning (SemVer)
 
-With the SemVer system you release version numbers that reflect the nature of changes (major, minor, patch). Ensure all major versions reference their Payload compatibility.
+With the [Semantic Versioning](https://semver.org/) (SemVer) system you release version numbers that reflect the nature of changes (major, minor, patch). Ensure all major versions reference their Payload compatibility.