Resource component folding via shareables

[WhitWaldo]

In reading through my notifications today, I saw this comment 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 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!

[stephaniezyen]

Thank you for bringing this up to our attention, we are planning to do some improvements in this area in the future.