Add string interpolatability to InlineHTML.

[JPToroDev]

String Interpolation Support for InlineHTML

This PR introduces string interpolation capabilities for InlineHTML, similar to SwiftUI's Text view. This enhancement allows for more expressive and dynamic HTML content creation within string literals.

Example Usage

struct Important: InlineHTML {
   init(_ text: String) {
       self.text = text
   }
   var text: String
   var body: some HTML {
       Span(text)
           .foregroundStyle(.red)
           .fontWeight(.bold)
   }
}

You can now use this custom InlineHTML element directly within strings:

Text(markdown: #"""
Swift protocols define a blueprint of methods, properties,
and other requirements that suit a particular task or functionality.
\#(Important("Note:")) The protocol can then be adopted by a class, structure,
or enumeration to provide an actual implementation of those requirements.
"""#)

Implementation Details

The changes to make this work are actually very small. The reason so many files are touched is because:

func render(context: PublishingContext) -> String

Has become:

func render(context: PublishingContext?) -> String

Most HTML elements don't utilize the context during rendering. Making the context optional enables string interpolation for inline elements with minimal changes to the current architecture.

[JPToroDev]

I'm going to resubmit with a better approach.

[twostraws]

Okay. I did read this through and didn't feel comfortable about the publishing context being optional when really it's always present, but it made me wonder whether the publishing context is really some sort of singleton – it would allow us to remove it from the render() method entirely.

[JPToroDev]

I was wondering that too while putting this together. I honestly think that is the better implementation.

The alternative is making context required again, and creating an empty PublishingContext to feed into InlineHTML's description property.

But every property of PublishingContext used in render() is a static piece of data that wouldn't change within a site.

I'll reopen this PR with that approach for you to review.

[JPToroDev]

Meaner and leaner.

[twostraws]

How come the subsite tests went away?

[JPToroDev]

I can re-add them, but I think that might be best in a separate PR. I think the subset tests need to be rethought a little. All but one of the subsite tests were testing elements that weren't tested for the regular site, so I moved them over there.

[twostraws]

Okay. Rather than re-add them, I wonder whether they could use Swift Testing's parameterized test system?

[JPToroDev]

Excellent idea. I think that should be possible. I'll put something together in a small follow-up PR. 🙌🏼

[twostraws]

This has a couple of conflicts, but otherwise I think it's good to merge.

[JPToroDev]

All set.

[twostraws]

Thank you!