You can configure pretty much as many as you like because until the policy is stuck to an interface, it is just a bunch of text within the configuration (I expect there is a #define value somewhere deep in the code which will limit your ability to configure more policies at some point, but in practice that is not where you will run into any limits).
Once you need to actually apply a policy to an interface then the answer to your question becomes "it depends" because different policies consume different resource on the NPU (queues, shape-rates, policer-rates) and it is these resources that are the finite limit on the device scaling. Something like Policers of class-default traffic are fairly lightweight in terms of resource consumption, whereas a HQOS policy with multiple queues at the child-level in the policy are resource intensive. Also, using the same policy-map on multiple interfaces will use less resources than applying slightly differently configured policies on the number of access-circuits.
The command to show the available resource on the device is "show qoshal resource summary" (probably best to try this in the lab, rather than on your production environment). If you attempted to apply a policy onto an interface that exhausts available resources on the NPU, then it will spit out a load of syslog messages and you will be left in no doubt that there is a problem with the latest attempt to change the config.
