feat(confluence-reader): add default parser framework and release 0.8.0

[tysonite]

Description

• Introduce a new default parser module and route both page HTML and attachments through a unified CustomParserManager pipeline
• Expand FileType coverage with PAGE_HTML, XLSB, MSG, and SVG, and export FileType from the package init
• Always initialize CustomParserManager, merge built-in parsers with user overrides, and allow custom_folder without requiring custom_parsers
• Move heavy parser dependencies into an all optional extra, keep core dependencies lean, and update lockfile/dependency layout
• Improve processing behavior by enforcing fail_on_error for attachments, adding page-id-aware error logs, and preserving parser metadata while keeping default metadata keys authoritative
• Remove legacy html_parser module and update tests, README, and CHANGELOG for new parser architecture and usage patterns

Backward incompatible changes

• Page bodies no longer use FileType.HTML. Previously, overriding FileType.HTML could affect Confluence page body parsing. After this change, page bodies are parsed via FileType.PAGE_HTML only, while FileType.HTML now applies only to HTML attachments.
• Prior to 0.8.0, installing llama-index-readers-confluence also installed all attachment-parsing dependencies (pytesseract, pdf2image, Pillow, docx2txt, python-pptx, pandas, openpyxl, pyxlsb, extract-msg, beautifulsoup4, svglib, reportlab) as core dependencies. Using include_attachments=True in load_data() worked without any additional install steps. As of 0.8.0, these dependencies have been moved out of the core package and into the [all] optional extra. Callers who use include_attachments=True must now install: pip install "llama-index-readers-confluence[all]". Without [all], calling load_data(..., include_attachments=True) will raise ImportError (or silently produce empty attachment text, depending on which file type is encountered) because the underlying parser libraries are no longer present.

New Package?

Did I fill in the tool.llamahub section in the pyproject.toml and provide a detailed README.md for my new integration or package?

• Yes
• No

Version Bump?

Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

• Yes
• No

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Your pull-request will likely not be merged unless it is covered by some form of impactful unit testing.

• I added new unit tests to cover this change
• I believe this change is already covered by existing unit tests

Suggested Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added Google Colab support for the newly added notebooks.
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I ran uv run make format; uv run make lint to appease the lint gods

[tysonite]

@logan-markewich I would appreciate it if you could find some time to review and upstream these changes. They are mostly refactoring. I have already tested them in my corporate project and plan to contribute a few more updates (e.g., comments parsing, PDF page parsing in addition to HTML, and some further cleanups).