[JENKINS-24938] Various fields should be transient

[JENKINS-24938](https://issues.jenkins-ci.org/browse/JENKINS-24938)

NOTE: not yet tested live.

I am trying to debug a customer’s Jenkins installation in which every time Jenkins is started, all the (custom) views disappear; after `cfg.unmarshal(Jenkins.this)` in `loadTasks`, `views.isEmpty()`. It turns out that if you delete all the EC2 slaves from `<slaves>` in `$JENKINS_HOME/config.xml` this problem does not occur. Furthermore, after unmarshalling, `slaves` has just one entry—an `EC2OndemandSlave`, the first listed before—even when there were originally several slaves of various kinds (including several EC2). So somehow deserialization of EC2 slaves is breaking deserialization of other, unrelated parts of the same XML file.

My suspicion falls on the `lastFetchInstance` field, whose serial form is quite large and contains several blocks such as

```
        <securityGroups serialization="custom">
          <unserializable-parents/>
          <list>
            <default>
              <size>1</size>
            </default>
            <int>10</int>
            <com.amazonaws.services.ec2.model.GroupIdentifier>
              <groupName>jenkins</groupName>
              <groupId>…</groupId>
            </com.amazonaws.services.ec2.model.GroupIdentifier>
          </list>
          <com.amazonaws.internal.ListWithAutoConstructFlag>
            <default>
              <autoConstruct>true</autoConstruct>
            </default>
          </com.amazonaws.internal.ListWithAutoConstructFlag>
        </securityGroups>
```

The unusual XStream form is created by `SerializableConverter` and triggered by the SDK’s `ListWithAutoConstructFlag` which extends `ArrayList` with an extra field.

So there might be an XStream bug lurking here somewhere. But reading `EC2AbstractSlave` sources it became clear that `lastFetchInstance` (introduced in 0d23ea37911442a4c10fbab18ee6fc1cdb3a5e6c by @cormallen in 1.17) is meant only as a cache and should not have been serialized in the slave config to begin with.

So this (so far speculative) patch just makes that field `transient`, along with some others written during `fetchLiveInstanceData`. (Though not `tags`, since this seems to be treated specially, being set in the `@DataBoundConstructor`.)