Rename and move documentation pages for clarity

Description

This renames and moves documentation pages for clarity. Part of #799 (closed).

Move LGSVL from tutorials to installation

I think LGSVL can go into "Installation" because most people should install it. I'm open for suggestions how to phrase that in installation/index.md.

Split demos/ into running/odd-demos and running/subsystems

The "Demos" page already now makes a distinction: The comprehensive ODD demo(s), and smaller parts that tell you how to run and maybe test smaller pieces of the stack. This changes the folder structure to make the same distinction as the text.

Move tutorials into running/subsystems

The tutorials don't do (much) more than showcase specific pieces of functionality – de facto they are the same thing as subsystem showcases. So why don't we remove this confusing distinction and put them together – one less top-level item cluttering the navigation bar. I do think there is a place for tutorials: One that explain all the tricks around launching nodes, for instance. I just don't think we currently have any that are meaningfully different from subsystem how-tos.

Rename from "Demos" to "Running Autoware.Auto"

I am open to alternatively calling this section "Using Autoware.Auto". First, it makes sense, because everything related to running/using the stack is in there (except troubleshooting, that will be a different MR). Second, that structure is really nice because in the end we'll have top-level pages with a clear order: Installation -> Running -> Building -> Developing if you have ADE, and "Building" before "Running" if you don't. With "Tutorials" or "Troubleshooting" at the top level it was not really clear which activity they refer to.

Notes for reviewer

This is the second in a series of MRs.

Pre-review checklist for the author before submitting for review

Every developer is encouraged to be familiar with our contributor guidelines.

1. MR formalities
   1. "WIP" or "Draft" removed from the MR title
   2. MR title and description help a friendly human understand the problem solved
   3. MR has a link to the original issue in description
   4. MR is configured to allow commits from developers with access to push to the target branch
   5. Sensible notes for the reviewer added to the section above to facilitate review
   6. Target branch set correctly. Default: master
   7. MR assigned to a capable reviewer. Default: @JWhitleyWork
   8. Splitting the MR into smaller, easier-to-review merge requests was considered
2. Code and tests
   1. Code is properly formatted
   2. Tests affected by new code pass locally
   3. Reasonable coverage with unit tests of 90+%; else create a follow-up ticket
   4. Review any // TODO item added in the MR that can be addressed without the reviewer's help
3. Documentation
   1. New and modified code has accurate doxygen documentation
   2. Diagrams are committed

Checklist for the reviewer

Only the reviewer is allowed to make changes in this section!

Items not applicable to this MR are crossed out by the reviewer.

• For new nodes, the checklist is expanded and reviewed
• For a new package, the checklist is expanded and reviewed
• Reviewer crossed out non-applicable items

Checklist

If the MR provides an improvement, don't hesitate to add a 👍 emoji for a neat line of code or a "Thanks for implementing this" comment. This will reward the MR author and prevent the review from being only about what still needs to be improved.

Mark all the items that are done.

Checklist for development

1. Basic checks
   1. The MR title describes what is being done on the ticket
   2. All functional code written in C++14, tooling code may be written in Python 3.5+ or Bash
   3. Commit messages formatted properly
2. Code correctness
   1. The problem/feature is solved (reproducibly)
   2. The solution is performant enough for the use case in mind
   3. Any disabled lints inside the code or at the package level are justified
   4. No 3rd-party license issue
3. Open work
   1. Any added source-code comment about future work refers to a follow-up GitLab issue explicitly; e.g., // TODO #551 refactor code below
4. Documentation
   1. New classes, methods, functions in headers are documented with doxygen-style comments
   2. If implementation (of a function...) is modified, the doxygen documentation is updated accordingly
   3. The design article is updated with the implementation
   4. Drawings are created when needed and committed to git
5. Testing
   1. Code coverage with unit tests does not decrease. Aim for coverage with unit tests of 90+%; else create a follow-up ticket
   2. Unit tests make sense and cover the business logic and error cases
   3. For a new ROS2 node, at least the basic launch integration test is included
   4. Integration tests are sensible and not flaky

Checklist for new ROS2 nodes

1. Every nodes is registered as a component
2. The naming conventions are followed

Checklist for new package

1. Structure
   1. The package name and organization into files is sensible
   2. Core functionality is separated from the ROS2-specific part where reasonable
   3. There is a design document that explains the package at a high level
   4. All dependencies are explicitly included in package.xml with the proper <*depend> declaration

When starting from scratch, new packages should be created with the autoware_auto_create_pkg macro and they will automatically satisfy the following criteria.

1. If an existing package is added to AutowareAuto, it should match the output of autoware_auto_create_pkg regarding
   1. same set of linters
   2. visibility control
   3. finding build dependencies in cmake with ament_auto_find_build_dependencies()
   4. installing with ament_auto_package()

Post-review checklist for the author

After receiving approval:

1. Rendered documentation looks as expected
2. All checkboxes in the MR checklist are checked or crossed out. Syntax example: 1. [ ] ~~this item crossed out~~
3. Developers were informed about breaking changes on slack in the committers-autoware-auto channel
4. Assign MR to maintainer with sufficient rights to merge. Default: @JWhitleyWork