Is your feature request related to a problem? Please describe.
In my development projects, database projects often have Merge scripts in PostDeployment scripts, to setup configuration data in a database. Also, we sometimes use PreDeployment scripts to perform certain DDL-operations that aren't well handled by the Publish action (create new non-nullable column without default constraint eg,). This is perfect when I want to publish to an existing database, or setup a new empty database with configuration data prepopulated in a test environment.
But I often need just the schema, without the data deployed. One use case is generating database subsets, where I publish the dacpac to create an empty clone of a database, and then populate it from the original database. When using the dacpac to create an empty clone, I do not want the PreDeployment and PostDeployment scripts to fire.
I also often deploy the dacpac to a container in the build pipeline and run automated tests. Pre-populated data is just in the way in this case - the test cases are constructed such that they create exactly the data needed to run the test.

Describe the solution you'd like
I would like two new parameters for the Publish Action (possibly for the script action as well):
/p:IgnorePreDeploymentScript - publish/script the model, but ignore PreDeployment script
/p:IgnorePostDeploymentScript - publish/script the model, but ignore the PostDeployment script

Describe alternatives you've considered
I could create the Pre- and Post scripts to only fire certain (or all) statements if a certain SQLCMD parameter is passed to them. But this is cumbersome, and oftentimes, I (DBA) have other use cases for the dacpac than the database developers, and therefore there's no real benefit for the database developers to construct the scripts this way.
My other workaround (which I currently use) is to publish the dacpac as a new database, and then have my subset-population-scripts empty every table which is not already empty. This too feels very sub-optimal - why go through populating the tables and then truncate them as the next step.

Additional context