Add documentation on how to read request data

[peruibeloko]

Didn't find any information on this topic in the entire Phoenix documentation, most StackOverflow questions related to this topic are from either 11 years ago and refer to Plug's read_body function or are referring to reading raw request data, which isn't my case.

This PR documents:

• How to access the request's body, path parameters and query parameters.
• Plug's "data merging" behavior
• The mix phx.new command with all --no-* flags for creating a bare bones JSON API.

As a new user of the framework, this sort of stuff is absolutely critical to get us through the door, especially for those of us coming from an "Express/Nest" style background and looking for better alternatives to do backend work.

I can't speak for all backend JS developers, but I feel like features such as LiveView and HEEx Templates, while flagship functionalities and core to the "Phoenix experience", are not the biggest priority in the adoption cycle for most of us. We're more interested in getting a simple backend service up and running before exploring other possibilities.

Feedback is more than welcome :)

[2025-12-30] EDIT: Just to be sure I didn't miss anything, I went over Plug's documentation once again and actually found some information on this. It's still a bit confusing as a newcomer, and I'd have to understand how Plug and Phoenix interact just to read some data, which is not ideal. I still think the change is worth considering.

[stjhimy]

https://github.com/phoenixframework/phoenix/blob/main/guides/controllers.md?plain=1#L67-L78

Maybe we could add the priority info as a single liner to the controller guide?

Phoenix merges path parameters, query string parameters, and request body parameters into a single params map. When multiple sources provide the same key, path parameters take precedence over body parameters, which take precedence over query string parameters.

[peruibeloko]

Could work as well! Lets keep this option around for maintainers to choose from.