Reorganization of ParseServerOptions

Is your feature request related to a problem? Please describe.
As Parse Server continues to evolve, so do the Parse Server options.

Describe the solution you'd like
There are certain options that in my view should be grouped together for neater organization, such as:

User Options:
-accountLockout
-enableAnonymousUsers
-expireInactiveSessions
-passwordPolicy
-preventLoginWithUnverifiedEmail
-revokeSessionOnPasswordReset
-sessionLength
-userSensitiveFields

Database Options:
-allowClientClassCreation
-allowCustomObjectId
-collectionPrefix
-databaseOptions
-objectIdSize
-protectedFields

REST Options:
-allowHeaders
-allowOrigin
-enableExpressErrorHandler
-middleware

Adapters:
-analyticsAdapter
-auth
-cacheAdapter
-databaseAdapter
-emailAdapter
-filesAdapter
-loggerAdapter
-push

Keys:
-clientKey
-databaseURI
-dotNetKey
-encryptionKey
-fileKey
-javascriptKey
-masterKey
-readOnlyMasterKey
-restAPIKey
-webhookKey

Server Info:
-appId
-appName
-cloud
-cluster
-customPages
-directAccess
-host
-jsonLogs
-masterKeyIps
-maxLimit
-mountPath
-port
-publicServerURL
-serverURL

Cache:
-cacheMaxSize
-cacheTTL
-enableSingleSchemaCache
-schemaCacheTTL

Email Options:
-emailVerifyTokenReuseIfValid
-emailVerifyTokenValidityDuration
-verifyUserEmails

Graph QL:
-graphQLPath
-graphQLSchema
-mountGraphQL
-mountPlayground
-playgroundPath

Idempotency:
-idempotencyOptions

Live Query:
-liveQuery
-liveQueryServerOptions
-startLiveQueryServer

Logs:
-logLevel
-logsFolder
-maxLogFiles
-silent
-verbose

Files:
-maxUploadSize
-preserveFileName

Push:
-scheduledPush

Server Events:
-serverCloseComplete
-serverStartComplete

I don't think every option requires categorization, but I think it could be handy to have all similar options tied together and cleaner in the docs, such as:

email : {
  verifyUserEmails: true,
  emailVerifyTokenValidityDuration: 2 * 60 * 60,
  preventLoginWithUnverified: false,
  resetTokenReuseIfValid: false
}

Considerations:

-How to handle options that could be under 2 categories, such as emailAdapter, which could be under adapters and email options
-This change would either need to be backwards compatible, or be a breaking change requiring changes to existing index.js.

The goal of this would be to ensure consistency and maintainability for ParseServerOptions, and to prevent them from continuing to bloat.

Please let me know your thoughts.

Start with the ParseServerOptions API documentation and the existing index.js referenced in the issue. Review the proposed option groupings and decide how overlapping options and backwards compatibility should work. Done means the organization is consistent and the documented configuration remains compatible or has an explicitly defined breaking change.