Add action button support for external package activities

[matsl]

What

Add action button support for external package activities.

Why

The activities package does not have a nice interface for using it as
action buttons. The activities are structs so are not supposed to be
inserted manually by the user. So the mapping function from activity
name to activity struct has to be used. The functions does also not
output an acknowledgment as a string to the minibuffer which is nice.

So these functions try to remediate that while keeping the same
naming convention and arguments as the functions from activities.

Update: Changed the PR to introduce one function for controlling create,
resume, revert and changing the default state. See Ideas 1 below.

Caveat

Using a prefix argument works fine for activating the action button when
using the menu but not when using the action key. That invokes the help
for the button. Not sure if that matters!?

Note

This does on purpose just add the functions for feedback. MANIFEST
item, and possibly tests, will be added if this is the way we want to
go. See ideas below for a maybe more Hyperbolish way...

Ideas 1

The action function could be overloaded with more functionality like
this:

• If no activity with that name exists, then create the activity
• If the activity is not active, switch to its latest state
• If the activity is active, revert it to its default state
• If the activity is active and action is called with a prefix then
  set the default state.

Then only one function could cover the cases for create, resume,
revert and define default state. Not bad!

Skipped idea

Ideas 2

Since we are redefining this to be different than what activities
provide we could define an implicit button for this. Something like

"Activity:Name"

[rswgnu]

Looks good. I would make an interactive and read the name, allowing for a new name.

[matsl]

@rswgnu Ready for review. No test case added.

[rswgnu]

Maybe I misunderstood your idea about an hsys-misc.el file. I thought that was for small external package interfaces. I think there will be a lot of activites integration points with activities so I would leave the hays-activities.el file.

[matsl]

Maybe I misunderstood your idea about an hsys-misc.el file. I thought that was for small external package interfaces. I think there will be a lot of activites integration points with activities so I would leave the hays-activities.el file.

😄 One function is a small interface. I have no big problem, only small, with having a separate file for it so I have reverted the changes.

Regarding the small problem: I think it is best to not design based on future anticipations. It can lead to overengineering and gold plating. XP (extreme programming) is a good thing! We should strive to adopt it IMHO.