Activity Visibility Improvements

[makigjuro]

This involves determining which Activities to display to a user in the activity chooser.

So far, we've defined a couple of classes of activity:

1. active, public, available to everyone
2. active but only visible to a subset of users (starting with the owner). This is for activities on in-development terminals, or terminals where the owner/creator wants to keep access private.
3. deprecated, which implies that the activity is still usable and active, but we don't want it choosable for new plans and new activities
4. inactive, meaning we don't want it seen, and we expect old plans with it to fail because it's not available for execution.

We generally never want to have activities in class 4. If an activity is not good or has been superseded by a better activity, we want to "put the activity out to pasture" and deprecate it, but not break old plans.

There's nothing in the Activity Template spec to specify this: https://github.com/Fr8org/Fr8Core/blob/dev/Docs/ForDevelopers/Objects/ActivityTemplates.md

If we used our Permissions system for this, we would rely on View Activity permission. The Hub delivers to the client a query of all activities that are active and for which the current user has View Activity and Execute Activity. To support this, when the Hub discovers a new ActivityTemplate, it would generate a default set of ObjectRolePermissions, allowing StandardUsers Fr8Admins to have View Activity and Execute Activity permission on it. When a Developer registers a new Terminal with the dev server, we should override that default method with a method that assigns these two permissions to the CurrentOwner Role, and the Admins and Fr8Admins but not the StandardUser. Later, we can add the ability for the Owner of a Plan to issue additional permissions.
To support the third scenario, we need a State that tracks whether an ActivityTemplate is Active or Deprecated or Inactive. In principle, we could envision this being specified in the ActivityTemplate. However, this is really a Hub decision. I think that for now we can get away with defining a State property in ActivityTemplate. This is optional for the data returned to a /discover call and should get stored in the ActivityTemplateDO in the db. However, we need a way for an admin to override this value from UI. That implies an Activity Details page that would be accessible from a list of Activities visible in the Terminal Details page. It should allow the State to be set to one of the three values, and immediately save that information (as well as log a Fact)