Resource component folding via shareables

In reading through my notifications today, I saw [this comment](https://github.com/Azure/bicep/issues/4158#issuecomment-1543675955) that reminded me of some functionality that was premature the last time I asked for something similar in #724, but which might be vastly easier today with the advent of [user-defined types](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/user-defined-data-types) and the notion of "shareable" resources in #10121

There are two resources that come immediately to mind, Virtual Networks and Application Gateways (I'm sure I can think of/find more with time), that must be created as a single PUT call and cannot be composed across multiple modules. This is unfortunate as those configurations are quite large and make for a wall of custom types (will be addressed with #9311 and #9570). But since we've got this notion of sharing things between modules in a way that results in the compiler simply flattening out all the pieces at compile time, it occurs to me that the time is ripe to resurface an ask regarding these monolithic types.

Ideally, I would be able to define different whole pieces of the resource (e.g. the whole of the parent object, the whole of each of the children of that parent) in separate files. Now, in today's Bicep, this means they'd be in separate modules, but I'd advise that because I wouldn't reference the pieces between each other as modules and would instead invoke them as "shareables" or imports, at compile-time, the whole of the intended resource would be assembled in the one module actually referenced by anything else, allowing a developer to simply build out the smaller pieces in these separate places and invoke local functionality there to build them out and take those outputs to fold into a single composite.

Further, especially as the imported values would themselves be strongly typed according to how they were constructed, the values could be easily manipulated with lambda functions to allow simple, but potentially sizable output construction of sets of inputs, significantly improving developer convenience, effectiveness and accuracy.

This would provide a solution to other tickets such as #4992, resolve the linked comment above and even for those resources that are more readily modularized, it would click in place as a consistent means of supporting such composition across all Azure resources whether they're legacy and monolithic or modern and modularized.

Thank you for the consideration!

The issue names no files, tests, or entry points. Start by reviewing the shareables proposal in #10121, the user-defined types documentation, and related requests #724 and #4992; determine the language and compiler changes needed to assemble strongly typed resource pieces at compile time, with composition across separate files as the done condition.

Written by the indexing model from the issue text.