[BUG] org-element-interpret-data does not preserve blank lines after elements

[chris <inkbottle007@gmail.com>]

Hello,

```
GNU Emacs 30.0.93
Org mode version 9.7.16
```

I'm reporting a potential bug in the `org-element-interpret-data` function of 
Org mode.

*Description:*

When using `org-element-interpret-data` as the reciprocal of `org-element-
parse-buffer`, I've noticed that blank lines before elements are preserved, but 
blank lines after elements are not. This behavior diverges from the 
expectation set by the Org Element API documentation.

*Documentation Reference:*

From the [Org Element API documentation](https://orgmode.org/worg/dev/org-element-api.html#other-tools):

> `org-element-interpret-data` is the reciprocal operation of `org-element-
parse-buffer`. When provided an element, object, or even a full parse tree, it 
generates an equivalent string in Org syntax.
>
> More precisely, output is a normalized document: it preserves structure and 
blank spaces but it removes indentation and capitalize keywords. As a 
consequence, it is equivalent, but not equal, to the original document the AST 
comes from.

*Steps to Reproduce:*

Consider the following minimal example:

```emacs-lisp
(let*
    ((hello-string-in
      "* hello

how are you


** hello-world

This is a programming section.
")
     (tree (with-temp-buffer
             (org-mode)
             (insert hello-string-in)
             (org-element-parse-buffer)))
     (hello-string-out
      (org-element-interpret-data tree)))
  hello-string-out)
```

*Expected Behavior:*

The output (`hello-string-out`) should preserve the blank lines both before 
and after elements, matching the structure of the input string.

*Actual Behavior:*

The output is:

```
* hello

how are you
** hello-world

This is a programming section.
```

As shown, the blank lines after "how are you" are missing, while the blank 
lines before are preserved.

*Use Case:*

This behavior affects buffer-editing operations where transformations are made 
on the Abstract Syntax Tree (AST). For example, when uppercasing headline 
titles:

```emacs-lisp
(let*
    ((hello-string-in
      "* hello

how are you


** hello-world

This is a programming section.
")
     (tree (with-temp-buffer
             (org-mode)
             (insert hello-string-in)
             (org-element-parse-buffer)))
     (_ (org-element-map tree 'headline
          (lambda (el)
            (let* ((title-data (org-element-property :title el))
                   (title-string (org-element-interpret-data title-data)))
              (org-element-put-property el :title (upcase title-string))))))
     (hello-string-out
      (org-element-interpret-data tree)))
  hello-string-out)
```

The output is:

```
* HELLO

how are you
** HELLO-WORLD

This is a programming section.
```

Again, the blank lines after "how are you" are not preserved.

*Additional Example:*

Changing TODO keywords demonstrates the same issue:

```emacs-lisp
(let*
    ((hello-string-in
      "\n\n* hello\n\nhow are you\n\n** hello-world\n\nThis is a programming 
section.\n")
     (tree (with-temp-buffer
             (org-mode)
             (insert hello-string-in)
             (org-element-parse-buffer)))
     (_ (org-element-map tree 'headline
          (lambda (h)
            (org-element-put-property h :todo-keyword "DONE"))))
     (hello-string-out
      (org-element-interpret-data tree)))
  hello-string-out)
```

The output is:

```
* DONE hello

how are you
** DONE hello-world

This is a programming section.
```

Despite the initial blank lines in the input, the output lacks the blank lines 
after elements.

*Conclusion:*

The issue seems to be that `org-element-interpret-data` does not preserve 
blank lines after elements, contrary to the expectation that it "preserves 
structure and blank spaces." This can hinder user experience when using these 
functions for buffer editing purposes, where maintaining the original 
document's spacing is important.

Best,

Chris