[Feature Request] Understanding onnxruntime performance

Currently the only performance profiling documentation one can easily find is https://onnxruntime.ai/docs/performance/tune-performance/profiling-tools.html. When one wants to understand the overall performance of onnxruntime (start up, IO, computation, memory usage), they often need to go through multiple tools to gather information, sometimes recompile from source (e.g. cuda), and worse get stuck because it is undocumented (memory usage). We also don't expose enough information to correlate the model execution with the onnx graph (with node metadata, etc.)

In comparison, PyTorch has built-in, easy to use, well documented profiling tools (https://docs.pytorch.org/tutorials/recipes/recipes/profiler_recipe.html, https://pytorch.org/blog/understanding-gpu-memory-1/) both for runtime and memory profiling.

Nvidia also provides a tool (https://developer.nvidia.com/nsight-dl-designer) that does onnxruntime profiling, but it is not able to provide the same level of detail than their own TensorRT, again because ort does not expose detailed runtime trace information.

See also TensorFlow's profiler: https://www.tensorflow.org/guide/profiler, which is integrated and detailed.

It would be fantastic to have similar capabilities in onnxruntime, both for developers and users to diagnose performance issues, and identify opportunities for performance improvement.

**The goal is to have a standard, ready out-of-the-box way to capture a full picture of ORT model execution performance in human consumable + programmatic accessible formats.**

To take a step further, we can have an agent that analyze performance reports and make improvement suggestions.

Start by reviewing the existing profiling documentation at onnxruntime.ai/docs/performance/tune-performance/profiling-tools.html and the PyTorch profiler examples linked in the issue. Define a standard out-of-the-box way to capture startup, I/O, computation, memory usage, and model-to-graph correlation in human-readable and programmatic formats; the issue does not name implementation files or tests.

Written by the indexing model from the issue text.