Add support for onProgress event when using Chunked Transfer Encoding fixes #17823

### Background
* **Chunked Transfer Encoding definition:** http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
* **Progress Event Content-Lenth and lengthComputable attribute in relation to Chunked Transfer:** http://www.w3.org/TR/progress-events/

> To fire a progress event named e means to fire an event named e with an event using the ProgressEvent interface that also meets these conditions:
> * Initialize the **loaded** attribute to the number of HTTP entity body bytes transferred
> * **If the length of the HTTP entity body is known** through the Content-Length header, initialize the **lengthComputable** attribute to true and initialize the total attribute to the length.

### The problem
When dealing with *chunked* transfer encoding and dojo/request the underlying `xhr` object properly reports the progress using the `onProgress` event, with `readyState` of `3`, but the dojo wrapper (dojo/request/xhr); only considers a progress event when the `lengthComputable` property of the event is `true`. 

By definition a *chunked* response can not report the total length of the response because generally is build on the fly. Also the Content-Length header must not be sent for chunked responses. So there is no way to *compute* the length. 

In summary, using dojo/request we can not be informed about the progress of a *chunked* response due to the missing info about the total length. Treating a very large response, that was transferred as chunked , like a normal one. Without the possibility to get the individual chunks the caller is forced to wait until the final bits.

### Proposal ( #17823 )
Modify the `dojo/request/xhr` wrapper to consider a *progress* event when the `Transfer-Encoding` header value is `chunked` and the `readyState` is 3 (*LOADING*).