Feature Request: Support multi-metric triggers for continuous profiling

Is your feature request related to a problem? Please describe.

Currently, go-zero continuous profiling only supports CPU utilization threshold as the only trigger condition. However, many common online anomalies including memory leaks, gradual heap growth and goroutine leaks often do not come with elevated CPU consumption. This creates critical observability blind spots: these stability hazards will fail to trigger auto continuous profiling, leaving us unable to collect stack traces proactively before OOM errors or service performance degradation happen.

Describe the solution you'd like

I hope to extend the continuous profiling mechanism to support multiple configurable trigger metrics, not limited to CPU:

• CPU usage (existing)
• Heap memory usage threshold
• Goroutine count threshold

Each metric should support independent threshold configuration. The profiling should be triggered once any metric exceeds its threshold, while keeping full backward compatibility with the original CPU trigger logic.

Describe alternatives you've considered

Currently, I have to manually trigger pprof or rely on external monitoring systems to find abnormal memory/goroutine trends, which is passive and untimely. There is no native way in go-zero to automatically sample profiling when memory or goroutine metrics drift abnormally.

Additional context

For IO-intensive services, queue consumers and long-running background workers, memory growth and goroutine blocking/leaking are far more common than CPU spikes. Supporting multi-dimensional profiling triggers will greatly improve the observability and fault preemption capability of go-zero microservices.