remove call to org-element-parent

this seems to be inconsistently supported.  It does nothing interesting, so it
makes sense that it isn't supported everywhere

Small bug, but worthy of a release

Version 0.6.1

Small news correction

Release 0.5.5

0.5.4 version bump, manual regeneration, ELPA badge

Manual updates are a result of updated org that evidently had some tweaks to the
ox-texinfo.

version bump

Fix mode check for dslide-develop command

And.. no more trusting random suggestions from the mailing list.  That was one
of 3 typos of the variety I would not expect when suggesting changes.

line noise

Signed-off-by: Psionik K <73710933+psionic-k@users.noreply.github.com>

Rename DSLIDE_SECTION_ACTIONS -> DSLIDE_ACTIONS

A followup to the removal of the child action.  There is less need to be
distinct, and this simplifies the configuration API just a bit more.

While `section-actions' is still used internally in some places, and its meaning
should be well understood by org hackers.

Signed-off-by: Psionik K <73710933+psionic-k@users.noreply.github.com>

version 0.4.0, some breaking changes

Child actions that were fiddled with for 0.3.x might break with 0.4.0, not that
any of this should have been stable.  It was very fiddly to write child actions
in 0.4.0

In 0.5.0, there is a strong chance that I combine child / slide action into just
multiple slide classes

Repeated development is revealing inherent coupling between the child and slide
action.  Their lifecycles are ambiguously encompassing and only the slide object
will be able to figure this out.

On the plus-side, it makes configuring the slides much, much easier.  Some of
the hydration code will die

The downside is that slide and child action won't be independent able to
articulate, but like I said, for the most part, they are not independent at all,
and what you want to do with the children is affected by what you do with the
slide, especially the restriction handling

Signed-off-by: Psionik K <73710933+psionic-k@users.noreply.github.com>