docs: add docs for agnocast tracepoint

[kobayu858]

Description

Added tracepoint definition documentation for Agnocast. Two new files are created for initialization and runtime tracepoints respectively, and links and descriptions are added to the existing index.md and agnocast.md.

Related links

• caret_trace: feat: add agnocast node tracepoints  caret_trace#326
• caret_analyze: feat: add agnocast node tracepoints caret_analyze#587

Notes for reviewers

Pre-review checklist for the PR author

• I've confirmed the contribution guidelines.
• The PR is ready for review.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR has been reviewed.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.
• The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

[xygyo77]

Since this is still a draft, it might be a bit early to mention this, but one minor point:
Currently, the alphabetical order puts Agnocast before the core features in both the sidebar and the page bottom navigation (Next/Previous).
I think it would be more intuitive to have the core features first, followed by the Agnocast points.

[github-actions]

Documentation URL: https://tier4.github.io/caret_doc/pr-380/
Modified URLs:

• https://tier4.github.io/caret_doc/pr-380/design/software_architecture/agnocast/
• https://tier4.github.io/caret_doc/pr-380/design/trace_points/agnocast_initialization_tracepoints/
• https://tier4.github.io/caret_doc/pr-380/design/trace_points/agnocast_runtime_tracepoints/
• https://tier4.github.io/caret_doc/pr-380/design/trace_points/

[kobayu858]

@xygyo77
I've addressed this as follows.
Changed the trace_points reference in docs/design/.pages to a flat format and added trace_points/.pages to control the page ordering. This change slightly alters the appearance of the Tracepoints section in the sidebar (one less level of nesting).

Background: Why this approach was chosen
In the awesome-pages plugin (v2.9.1), when a parent .pages uses a virtual section structure, the child directory's .pages is ignored. (issues/77)
The v2.9.2 release notes mention "Fix .pages in sections under virtual section 77", but when I upgraded to v2.10.1 and tested, the child .pages was still not respected, and it also caused unintended changes to the existing design, so I decided not to adopt it.
I also considered adding prefixes to file names to control the order, but avoided this approach since it would change the URLs.

Please let me know if you have any thoughts on the above.

[xygyo77]

Thanks for the detailed investigation and explanation regarding the awesome-pages plugin issue.

I understand the reason for choosing the flat format to avoid the plugin's bug and preserve the URLs. The change in the sidebar nesting is not a problem.

However, I’ve left a comment on the “File changes” tab. Please take a look at that as well.

[xygyo77]

LGTM

[xygyo77]

@kobayu858
I've approved the PR. Since the CI issue is now resolved, please merge it at your convenience.