Feat(UF) : Add frontend for unified form

[tr1ten]

front-end part of unified creation form

[MonkeyDo]

It's so awesome to see the feature getting so well set up !
You're doing a great job !

I commented on lots of details, which we would expect for such a big PR 😄
For now I didn't review the tests (by the way, also awesome to see the long overdue test harness for the front-end!), I figured we should start with that for now.

On my side i feel like I'm failing you a bit by not having thought through an important aspect.
I know it is very late in the game for this comment, but here it is: In view of some of the added complications of having these entity stubs (new entites created with modals) to deal with, we could reconsider that when an entity is added through the create modal we actually submit the entity for creation at that point, like the MB editor does.
If we get a BBID back from that request we can use the BBID directly. That will avoid some state complications, removing the custom deduplication code, etc.

We would still need the save-multiple-entities route because we will be creating links between all these entities.
Please let me know how you think we could approach that.

[MonkeyDo]

What was your final outcome with the validation state? Was it still slowing down the app too much? If so we'll unfortunately have to get rid fo the commented out code (and any other code that was just for this validation feature) [a moment of silence for the fallen bits].

[tr1ten]

Though after optimization this doesn't seem to cause any issue. but now i am not sure if we need validations on modal, let me know if you think we should keep the validations or not.

[tr1ten]

Hey, thanks for such a detailed review.

we could reconsider that when an entity is added through the create modal we actually submit the entity for creation at that point, like the MB editor does.

If i understand it correctly you meant submitting the modal directly to server and not storing entity state for later submission?
I did think about doing the same later realize it might not be a good idea for the following reasons -

1. It would be cumbersome to use the new entity for purposes like duplication where we need whole entity state.

2. Since this editor is mainly targeted (but not limited) to new user, they might make mistake during edit which can easily be fixed from current workflow.

3. Adding and removing attributes on entity is much easier now else we will need to create unnecessary revisions.

4. In current workflow, Summary tab may help user to review their entities and possibly fix them if needed giving more quality submissions.

5. lastly i believed that strategy might fall short in the long run when we start using UF editor for more complex workflow and may result in even more complication than we have now.

I apologize for not communicating my reasons well for current workflow properly during the proposal :.
If you still think these reasons don't worth the extra complication, then after some discussion on implementation details we can go ahead that strategy.

[MonkeyDo]

OK, after another review I'm happy to get this PR merged before it grows any larger :)

We still have some details to sort out which I will write out as separate feedback, but it can all be done in separate PRs now that we have this good functioning base.

Nice work ! :)
P.S: I've also deployed the current state of the PR to test.bookbrainz.org/create as requested