Draft: Add Security issue view components

What does this MR do and why?

⚠️ This is still a draft and I'd like some early opinions on the current work ⚠️

This MR is responsible for adding a view concern responsible for rendering security issue info on the blog post merge request. This will simplify how we conditionally render those views and enables us to reuse them elsewhere.

In case this component is reused in a different context than blog posts, the component can be moved at a higher level.

Discussion points

• The names are to be determined
• After extensive testing and evaluating what may be best from an API standpoint, I've decided to:
  • Write a view component that takes all security fixes and responsible for rendering the Markdown (ie: table and summary)
  • Write a view component representing each security issue entry for the table due to the complexity
  • This is in an effort to promote better testing, reusability and maintenance
• Here's a very simple flow for how the content will be generated:
  • Assuming every module lives under ReleaseTool::PatchRelease::BlogPost
  • 👇 MergeRequestContentGenerator#generate_blog_content: generates the entirety of the blog
  • 👇 In the multiple versions template (new_patch_release_template.md.erb), security_fixes_info renders all security info when applicable. Delegates to...
  • 👇 SecurityIssueInfo#generate: generates security fixes as info on templete security_issue_info.md.erb
    • ☑️ #security_fixes_rows renders the table rows
    • ☑️ #security_fixes_summary returns the summary for each security fix

Pros:

• ✅ Less cognitive load on the higher level class
• ✅ Separation of concerns, view separate from business logic

Cons:

• 🤔 More complex code
• 🤔 Naming (for now)

Content

• Add SecurityIssueEntry view component

Author Check-list

• Has documentation been updated?