It depends upon how you have your project configured but you don't need build events to do this.
If you are using the older project format (pre SDK) then you can use Batch Build. Batch Build tells VS to build any combination of projects and configuration/platforms. You can, for example, tell it to build the debug version of your x86 project and the release version of your x64 project. Behind the scenes though it is doing the same exact thing that you would do which is to build the first project combo and then the next project combo. This is the correct approach for pre-SDK projects. When MSBuild builds your project it'll only do 1 configuration/platform combination at a time and that makes sense.
If you are using the newer project format (SDK) then it is already set up to support multiple target frameworks, but not configurations. Using the ]TargetFrameworks attribute in the project file instead of TargetFramework
causes the build to generate a separate output for each target framework. This is how we use a single build to generate binaries for multiple frameworks such as .NET 4.7.2 and .NET 5. However, as already mentioned, it does not care about the configuration so you'd run the build for Debug or Release separately. It also doesn't work for differences in only bitness (x86 vs x64) although there might be a TFM that maps to bitness that I haven't seen before.
Ultimately I think the question is why you need this? For a VS build you probably only need to build a single configuration/platform as defined by the solution. Batch Build can be used if you need to build multiple mappings. But for a build server environment you're likely already using a build script (PS1, CMD, YAML, etc) so in most cases you'd just have the build script run multiple builds (perhaps based upon whether this is an official build, PR, etc). So for automated deployments it has less value.