More modular fields code

[bhousel]

We should probably improve how we handle fields in the iD codebase. This is something that @kepta and I were talking about recently.

All of our fields are currently written in a way that you can't just create a field, it's expected that presets "own" fields. The problem with this is when we want to create a special field inside some other field, the only way to do this is to duplicate a lot of code.

This impacts the bridge/tunnel radio field #3911 and @kepta's lane editor #3822, and whatever other "advanced" fields we want to create. In the case of the #3911, just to add a "Type" combo, I had to copy over a lot of the code from combo.js. This code duplication adds a bunch of technical debt, and we should clean it up once we find a better way.

We can probably fix this by splitting this UIField constructor (factory?) out into its own module, making sure to account for all the preset closure variables that it depends on (e.g. it should have its own dispatch, etc). We might be able to do this without a major semver bump.

[kepta]

@bhousel I really like the idea. After working on #3822 I realised we definitely need something like this.
It would be great if we could chalk out the list of things we would need to do for this refactor.
And also I was wonder for this new refactor will we still have the
custom events or should we look into other design patterns, since we are changing the whole submodule.

[bhousel]

A field in a field.. This is cool that it works.

I liked the previous trimmed down design of this layer field, so I will make sure we can construct fields without the label, frame, form buttons if we want to.

[kepta]

This is amazing @bhousel !!

[bhousel]

Done in #4214 😄