No repeat functions and individual approval exception decisions

As a ministry user I want the exceptions to be approvable individually and not need to be re approved when there is an edit and no changes have occurred to the data related to the exception.

Create a container for each exception that encompasses all the questions that related to it. TBD list of components or hybrid approach could be better. analysis being done as a part of first effort

Make a new element from that container of mapped questions

On edit be able to ID if any of the questions within the container were changed

If no then do not re trigger the need for the exception to be approved

Create functional approval process that allows each exception to be approved indivuidually

### Exception baseline AC's
- [ ] Utilize validation and mapping of changed application data during an edit to be able to identify if an exception question has changed
- [ ] Be able to validate if an exception has already been approved and use that validation for future processes. It is important that it is **approved** not just a decision has been made. If the exception was declined it must still reproduce the exception.
- [ ] Create a logic path for if an exception should be retriggered after an edit.
If Exception approved = True and question changed = false then do not re trigger exception process for that question
Else trigger exception (please note this is generic logic without created validation data variables)

- [ ] Program year 25-26 onward for ft
- [ ] program year 26-27 onward for pt
- [ ] If an exception is already triggered and is pending a decision we will not change that
- [ ] All current applications that have a new edit submitted should have this logic apply (assumption is that we can get the historical approval information easily for those applications)
- [ ] If none of the questions related to the exception have changed and the exception has been approved previously do not retrigger the exception
- [ ] If there has been no changes to any of these elements on edit submission then the exception will not trigger again and it will not be needed for it to be approved again
- [ ] If a previously approved version exists and the data from the new submission matches the container exactly then do not retrigger the exception
- [ ] Ensure that any files in the uploader have the same name and content
- [ ] Utilize the edit comparison functionality built in the past that flags elements red to ID if anything has changed for the elements within the new container

### PIR not repeated

- [ ] Create container or component list for the entire program tab
- [ ] If any compenents have changed re trigger PIR
- [ ] If not reuse the previously attached PIR offering
### Technical AC baseline (waiting on analysis)
- [ ] Create a new element that maps multiple questions to a new "container" could be named whatever makes sense
- [ ] Capture all questions in the additional transportation question within the container or equivalent solution that allows us to recognize questions associated with an exception

Analysis being done in first ticket to id the best path forward

**Baseline Tests**
Test 1
Complete edit where current year income exception was already approved on base app
Submit a change where there is no changes to the current year income question
It should not be required to be approved again
Test 2
Complete edit where current year income exception was a part of the base app but was not approved yet
Submit a change where there is no changes to the current year income question
The exception process should be recreated attached to the new edit and await approval
Test 3
Complete edit where no exceptions included in base app
complete an edit that adds a current year income exception
Exception should be created for current year income exception
Test 4 
Complete edit where current year income exception was already approved on base app
Submit a change where there is no changes to the current year income question
It should not be required to be approved again at this point
Submit a 2nd edit where you add an additional support document upload to the current year income exception
It should trigger the need to complete the exception

**Additional Context**
- This resolves a large service delivery work load concern but also links to future functionality of change requests