ER: Potential XSS Vulnerability in wins.js

### Emergent Requirement - Problem
I originally submitted this as a security advisory, but @roslynwythe said there isn't a way to convert it to an issue so I'm reposting it here

Original text:
> ### Summary
> The usage of innerHTML to dynamically modify DOM elements in wins.js may introduce a vulnerability to Cross-Site Scripting (XSS) attacks if wins-data.json is compromised, not properly sanitized, or not adequately vetted.
>
> ### Details
> The vulnerability exists on the following lines of code where DOM elements are dynamically modified using external data.
>
> https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L339
> https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L340
> https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L498
> https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L501
> https://github.com/hackforla/website/blob/gh-pages/assets/js/wins.js#L504
>
> To address this vulnerability, it is recommended to avoid using `innerHTML` and prefer safer DOM manipulation methods like `createElement` and `textContent`
>
> Additionally, the unformatted nature of `wins-data.json` can make it difficult to spot changes in the file with a git diff. Consider reformatting the JSON file to be more human-readable and version control-friendly.
>
> ### PoC
> The [vulnerability audit](https://docs.google.com/document/d/1aJxb7KPL4zQKL1XUR8mwzP4tY6c3m223OpDmhX9MmEg/edit) states that "User input strings remain strings and escape injection through `decodeURIComponent()`" however, in my testing this is not the case and strings parsed through `decodeURIComponent()` are still susceptible to XSS.
> Proof of concept: https://codepen.io/jaasonw/pen/GRPBzGJ
>
> ### Impact
> Potential defacement of the website or visitors being subject to phishing attacks.

### Issue you discovered this emergent requirement in
- Originally discovered while reviewing https://github.com/hackforla/website/pull/5258, however it was not introduced by that PR

### Date discovered
10/1/2023

### Did you have to do something temporarily
- [ ] YES
- [x] NO

### Who was involved
@

### What happens if this is not addressed
> Potential defacement of the website or visitors being subject to phishing attacks.

### Resources
https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent
https://medium.com/front-end-weekly/javascript-innerhtml-innertext-and-textcontent-b75ec895cbe3
https://jekyllrb.com/docs/datafiles/

### Recommended Action Items
- [ ] Make a new issue
- [ ] Discuss with team
- [x] Let a Team Lead know

### Potential solutions [draft]
option 1
> Update code that does DOM manipulation. Instead of using `innerHTML`, we should update the code to use safer DOM manipulation methods like `createElement` and `textContent`

option 2
Alternatively, I noticed a lot of the data on the website is loaded in on page load with javascript rather than at build time. Seeing as we already use Jekyll, I suggest using its [built-in functionality](https://jekyllrb.com/docs/datafiles/) with the [strip_html filter](https://shopify.github.io/liquid/filters/strip_html/) to load data into the HTML at build time statically, as this has benefits to both page load times and accessibility benefits to visitors to the site that have javascript disabled