[WIP] Explicitly disallowing serialization of objects as controller attributes...

... in non-inline fragment renderers

| Q             | A
| ------------- | ---
| Bug fix?      | possibly
| New feature?  | no
| BC breaks?    | possibly
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #7124
| License       | MIT
| Doc PR        | none

Right now, the fragment renderer accepts a controller reference with a set of attributes/parameters. When rendering inline, any attributes that are objects get passed directly to the subrequest. When rendering as a URL (e.g. for ESI or HInclude), those objects are serialized by the http_build_query function. This change makes URL rendering steps explicitly reject any object values instead of letting http_build_query serialize them.

Why? Consider the case where we are passing a DB entity as controller param to be rendered using the ESI or HInclude strategy. Either way, the developer has to pass an ID instead of DB entity itself for this to work - http_build_query lacks intelligence to automatically convert the DB entity into just its ID value.

This change does not add the intelligence to convert entities into IDs, but still explicitly reminds the developer to not pass the object directly when non-inline strategies are used, thus reducing silent bug-causing behaviour.

NOTE: this needs discussion regarding BC breaks. In theory, nothing should break. In practice, others' code may have relied on quirks of serializing/unserializing params via http_build_query. Non-inline fragment renders should be least susceptible to breakage; inline fragment renders are more susceptible - e.g. integer params used to be forced into strings through the query encoding step, and some comparisons may start breaking because of that.