WIP: Convert blog middleman instance to a dedicated CI job and remove need for symlinks

What

Convert blog Middleman config to be a dedicated CI job, and not require symlinks.

How

The current plan is to use the same approach for the blog sub-site that we used for the part 1 of the handbook monorepo refactor.

Tasks

(Note: Some of these have already been done in separate MRs)

• Resolve circular dependency in https://gitlab.com/gitlab-com/www-gitlab-com/blob/8a666d57f4b9508d75a5888a29fc491ceefdd1a8/source/includes/recent-posts.html.haml#L4-4
• Move /releases/gitlab-com/index.html out from under releases and redirect (it doesn't use the releases template, and requires generators data, so it doesn't belong there, at least not for this phase of the move).
• Make necessary updates to sites/blog/config.rb middleman config
• Move proxies from top-level config to blog config.
  • blog/categories/<category>/index.html
• Remove references to blog from top-level config
• Delete extensions/listen_monkeypatch
• Skip blog in PartialBuild
• Compare CI performance of single build to PartialBuildBlog.
  • See how much time is actually saved, and if it's still necessary, or can be avoided and removed along with the blog post specific logic in the CI file.
• Abstract out OnlyBlogResources / OnlyHandbookResources.
• Abstract out duplication across config files.
  • Possibly split into multiple common include files, to allow easier overriding? Only if it makes sense and doesn't seem like premature optimization.
• Remove broad regex matches in shared_files config, and replace with individual filenames.
• Remove orphaned file under source/posts
• Remove commented config sections
• Look into DRYing up duplicated YAML load/parse of data/monorepo_sites.yml
• Update/move all occurrences of source/releases
• Doublecheck coordination of #7983 (closed), if it is still in progress and not merged.
• Separate CI job for releases proxy resource which uses generator/releases.rb which accesses the API.
  • QUESTION: Does it need a separate caching strategy, or is this only needed for the Direction generator?
• Final compare with master to doublecheck that includes/blog files have not changed.
• Final pass of config, remove all unused commented code.

Additional unrelated tasks

Do these as separate MRs, tracking them here for now:

• Fix all occurrences of File.expand_path("#{monorepo_root}/source", __dir__) (no necessary to expand if monorepo_root is used, because it's already an absolute path).
• Revisit approach of including common files to remove unnecessary complexity and per-site customization:
  • Don't need to have extensions/middleman_source_watcher_find_monkeypatch.rb or multiple files.watch entries. These were an unnecessary optimization to avoid watching the entire root source directory, but that's unnecessary if we use a curated only list. So, on master (backported to handbook)...
  • remove the monkey patch
  • go to a single files.watch entry for source
  • have its list of only be data-driven by data/monorepo_site_paths.yml (may need to restructure it to have different keys).

Related issues

Closes #7972 (closed)