Long term for Logstash documentation

@karenzone, @lcawl, and I met to discuss Logstash/V3 today. Here are some notes and recommendations.

## Summary
Logstash documentation consists of two main content sets:

1. [**Logstash Reference (LSR)**](https://www.elastic.co/guide/en/logstash/current/index.html): Contains reference content from the [logstash](https://github.com/elastic/logstash) repo and plugin reference content from the [logstash-docs](https://github.com/elastic/logstash-docs) repo.
2. [**Logstash Versioned Plugin Reference (VPR)**](https://www.elastic.co/guide/en/logstash-versioned-plugins/current/index.html): Entirely sourced from the [logstash-docs](https://github.com/elastic/logstash-docs) repo.

The `logstash-docs` repo acts as a middle-ground repository that houses all built AsciiDoc documentation for Logstash plugins.

## The problem
The current automation for Logstash documentation is error-prone and time-consuming to manage. Rewriting this automation is necessary, but neither docs-eng nor logstash-eng has the resources to accomplish this by March 25. A practical plan is needed to determine what can realistically be done by this deadline.

## Options

### 1. Leave all Logstash docs behind
We would not migrate Logstash docs to V3 at this time. Instead, we would connect the Logstash AsciiDoc content with the V3 experience and modify the legacy AsciiDoc tooling to allow this functionality. This option avoids additional V3 engineering work but requires tooling on the unknown Asciidoc build side. It is also likely to result in a poor user experience.

I'm really worried about this option because I don't know what is required on the Asciidoc side. Removing all of the other `main` and `master` docs will really bork up the Asciidoc build. There be 🐉's and I'm afraid this will turn into to way more work than we think.

### 2. Treat LSR and VPR as separate content sets (migrate some)
This approach would migrate the LSR to V3 **without** the plugin content and leave the VPR in AsciiDoc. While this simplifies the migration for part of the Logstash docs, it significantly degrades the user experience since Logstash is not functional without its plugins.

I see no win with this option. It's a poor user experience and combines all of the cons from both options 1 and 3.

### 3. Migrate both content sets repeatedly with adoc-to-md

1. Maintain the existing automation and layer the [adoc-to-md](https://github.com/elastic/adoc-to-md) migration tool on top of it.
1. Split the LSR into two `toc.yml` files:
1. MD reference content (which will live in the logstash repo).
1. MD plugin docs (which will live in the logstash-docs repo).
1. Keep the VPR entirely in the logstash-docs repo with its own `toc.yml`.
1. Use GitHub Actions to automate the `adoc-to-md` conversion script after each commit to the logstash-docs repo.
1. Source all three toc.yml files with the assembler

Differs a complete automation rewrite, offers a good user experience, and it might actually not be that difficult to implement.

I think it's worth further exploring option 3

## Related

* Further musings, research, and discussion on a possible long term plan are in https://github.com/elastic/platform-docs-team/issues/409.
* Previous attempt at updating versioning in the VPR: https://github.com/elastic/docs-tools/pull/70