editing a test should add the test> prefix

[stew]

if I edit a test, it should add the test> prefix to the function so the test gets run after editing.

I have found that we have inadvertently turned tests into regular functions when they show up on our todo and we save the function without manually re-adding the test> prefix :(

[stew]

```ucm
.> pull unison.public.base.latest lib.base

```

```unison
test> oneAndOneAndOne = check ((1 + 1 + 1) === 3)

```

```ucm
.> add
```


```unison
oneAndOneAndOne = check ((1 + 1) === 3)
```

```ucm
.> update
.> view oneAndOneAndOne
```

```ucm
.> pull unison.public.base.latest lib.base

  ✅
  
  The destination lib.base was empty, and was replaced instead
  of merging.

```
```unison
test> oneAndOneAndOne = check ((1 + 1 + 1) === 3)

```

```ucm

  I found and typechecked these definitions in scratch.u. If you
  do an `add` or `update`, here's how your codebase would
  change:
  
    ⍟ These new definitions are ok to `add`:
    
      oneAndOneAndOne : [Result]
  
  Now evaluating any watch expressions (lines starting with
  `>`)... Ctrl+C cancels.

    1 | test> oneAndOneAndOne = check ((1 + 1 + 1) === 3)
    
    ✅ Passed : Proved.

```
```ucm
.> add

  ⍟ I've added these definitions:
  
    oneAndOneAndOne : [Result]

```
```unison
oneAndOneAndOne = check ((1 + 1) === 3)
```

```ucm

  I found and typechecked these definitions in scratch.u. If you
  do an `add` or `update`, here's how your codebase would
  change:
  
    ⍟ These names already exist. You can `update` them to your
      new definition:
    
      oneAndOneAndOne : [Result]

```
```ucm
.> update

  ⍟ I've updated these names to your new definition:
  
    oneAndOneAndOne : [Result]

.> view oneAndOneAndOne

  oneAndOneAndOne : [Result]
  oneAndOneAndOne =
    use Nat +
    check (1 + 1 === 3)

```

[aryairani]

Ok we have a few things here:

1. When editing something that IsTest, it should be added to the scratch file as a test> watch.
2. I would expect that in trunk right now, the updated test would still inherit IsTest from its predecessor, despite not having test> in the scratch file. Is that not the case?
3. We don't want it to inherit IsTest from its predecessor when it's not marked as a test> watch, because this deprives you of the ability to intentionally make something not a test. But is update really what you want here anyway?
4. Why do we even have IsTest? Would it be more accurate from the type of the definition? (e.g. is it [Test.Result], or whatever that hash is).
5. Do we even like test>? Should we just use the type here as well?

[aryairani]

Proposal: For now, just do 1.) 3.) Can be a separate effort. And we can discuss 1-5 further.

[ceedubs]

I think that this is a duplicate of #1745.